Actualizar

Subir de versión en un paquete 0.x es leer lo que rompe antes de quedártelo. Eso es lo que hace este comando: instala, te enseña el CHANGELOG de lo que acaba de entrar, y solo entonces te pregunta si te la quedas.

pnpm cms update             # el salto entero, con dos confirmaciones
pnpm cms update --dry-run   # solo enseña; no escribe nada

--dry-run corre únicamente el npm view del registro, que es de lectura: imprime el salto y el plan de peers y termina con 0 sin haber tocado un byte. Sin el flag, lo mismo, y después la primera pregunta.

Cómo se lee el salto

@kevolution-co/cms 0.7.0 → 0.8.0
  drizzle-orm  1.0.0-rc.4 → 1.0.0-rc.5
  drizzle-kit  1.0.0-rc.4 → 1.0.0-rc.5  (-D)

La primera línea es el paquete: de la versión que tienes instalada en el proyecto a la del destino. La instalada se busca subiendo desde tu cms.config.ts por los node_modules, no es la del binario que corre — con pnpm dlx son distintas.
Debajo va el plan de peers, y solo las que cambian. nombre de → a es una peer que el comando va a alinear él; el (-D) marca las que van a devDependencies.
Si no cambia ninguna, lo dice: Ninguna peer cambia.

El destino y sus peers salen del registro —es lo único que sabe qué exige una versión que todavía no tienes—, preguntados con npm view desde la carpeta del proyecto.

Qué significa que en `0.x` la menor pueda romper

Hasta la 1.0.0, una versión menor es una ruptura posible. La política está escrita en .changeset/README.md, que es la misma que cita el README del paquete, y cada ruptura viene marcada como BREAKING en el CHANGELOG.

Por eso este comando existe: enseña las rupturas antes de que te quedes con la versión, con las líneas marcadas destacadas.

Lo que cambia entre 0.7.0 y 0.8.0:
## 0.8.0
### Minor Changes
- **Comando nuevo: `cms init`** …

Lo que rompe se lee del CHANGELOG.md del paquete ya instalado, que por eso viaja dentro del tarball: el repositorio es privado y un token con solo read:packages no puede leerlo de ninguna otra forma. Si el paquete no lo trae, o no hay nada entre las dos versiones, el comando lo dice y te manda a leerlo antes de responder.

Las dos confirmaciones y la vuelta atrás

Son dos a propósito:

«¿Instalar la 0.8.0?» — antes de instalar. Decir que no sale con 0 sin haber tocado nada.
«¿Te quedas con la 0.8.0?» — después de instalar y después de leer el CHANGELOG.

Decir que no en la segunda restaura el package.json byte a byte y reinstala:

Volviendo a la 0.7.0: "/mi-sitio/package.json" restaurado tal cual estaba. Reinstalando…
Vuelta atrás hecha: sigues en la 0.7.0.
"/mi-sitio/package.json" está byte a byte como estaba, el rango incluido, y ninguna peer se ha tocado.

Byte a byte significa byte a byte: el rango que tenías escrito —^0.7.0, y no 0.7.0—, el orden de las claves, la indentación y el salto de línea final. Ningún comando de ningún gestor reproduce eso, y por eso la vuelta atrás restaura el texto en vez de desinstalar.

Las migraciones las ejecutas tú

cms update regenera .cms/ al terminar —lanzando el binario recién instalado, no el que está corriendo— y, si el CHANGELOG habla del esquema, avisa:

El CHANGELOG habla del esquema: ejecuta `cms db:migrate`, **lee el SQL** que deja en migrations/ y solo entonces `cms db:apply`. Esta actualización no aplica ninguna migración.

Pero no genera ni aplica ninguna. El ciclo sigue siendo el de siempre, y es tuyo:

pnpm cms db:migrate          # escribe el SQL en migrations/
                             # léelo
pnpm cms db:apply            # local
pnpm cms db:apply --remote    # producción, antes del push siguiente

Es la política escrita del paquete —nunca escribimos la migración por quien consume el paquete— y aquí se repite porque es justo el sitio donde se olvidaría. El detalle está en Schema y migraciones, y por qué el --remote va antes del push en Despliegue.

--no-regen salta la regeneración de .cms/; entonces la haces tú con cms db:generate.

Las peers

Las fijadas a una versión exacta se alinean solas a la que el destino declara: son las que no perdonan, porque una versión distinta ni siquiera arranca.
Las de rango —astro, react, react-dom, wrangler— no se tocan. Si el destino pide un rango distinto del que pedía la versión que tenías, el comando lo dice y te deja el comando exacto para alinearla tú: mover un rango es una decisión del proyecto, no del CMS.
Si una peer de tiempo de ejecución está en tus devDependencies, el comando la alinea donde está y avisa: instalada así desaparece de lo que despliegas. El mensaje trae los dos comandos para moverla.

Un nombre o una versión que el registro devuelva y no tengan la forma esperada no se instalan: se dicen en amarillo y se alinean a mano. Los flags —--to, --dry-run, --no-regen, --yes— están en la referencia del CLI.