Actualizar de 0.17 a 0.18

Actualizar 0.17 → 0.18

0.18.0 ya está publicada. Son las entradas ### Breaking de su sección del changelog, una a una, con lo que cada una te pide cambiar. En 0.x la versión menor es la que rompe, así que este es el muro entre 0.17.3 y 0.18.0: léelo antes de actualizar, no después.

20. defineCollection tiene una sola firma

Eran tres sobrecargas —Postgres, Firestore, MongoDB— y ahora es una, discriminada por engine (Postgres cuando falta).

Qué cambiar: nada en una llamada que ya compilaba; lo que cambia es dónde cae el error, ahora sobre la clave equivocada y no sobre defineCollection(. UnknownPropertyKey ahora se llama NoSuchKey: solo el código que importaba el nombre antiguo tiene algo que tocar.

21. defineCollection sigue comprobando tras la primera propiedad errónea

Una sola propiedad mal escrita colapsaba la entidad inferida a Record<string, unknown> y apagaba todas las demás comprobaciones.

Qué cambiar: nada que escribir, pero espera errores nuevos en archivos de colección que antes compilaban. Ya estaban mal entonces; el compilador había dejado de mirar.

22. El campo de enlace de una relación debe pertenecer a su kind

{ kind: "belongsTo", foreignKeyOnTarget: … } ya no compila.

Qué cambiar: escribe el campo que corresponde a esa clase de relación.

author: {
    type: "relation",
    relation: { kind: "belongsTo", foreignKeyOnTarget: "author_id", target: () => authors }
    relation: { kind: "belongsTo", localKey: "author_id", target: () => authors }
}

El validador de arranque ya lo rechazaba: si tu proyecto arranca hoy, compila hoy.

23. La validation de una relación sube a la propiedad

RelationBase.validation y ResolvedRelationBase.validation se han eliminado.

Qué cambiar: súbela un nivel, junto a la de cualquier otro campo.

author: {
    type: "relation",
    validation: { required: true },
    relation: { kind: "belongsTo", validation: { required: true }, target: () => authors }
    relation: { kind: "belongsTo", target: () => authors }
}

El arranque rechaza la clave antigua por su nombre. El código que preguntaba a una relación si era obligatoria ahora usa import { isRelationRequired, relationDeclaringProperty } from "@rebasepro/common".

24. Un belongsTo obligatorio borra con RESTRICT, no con CASCADE

Esto es un cambio de DDL. El próximo rebase db push planifica una reconstrucción de la restricción para cada relación obligatoria que nunca declaró un onDelete, y después los borrados del padre empiezan a fallar donde antes cascadeaban.

Qué cambiar: si quieres conservar el comportamiento anterior, escríbelo.

relation: { kind: "belongsTo", target: () => authors }
relation: { kind: "belongsTo", onDelete: "cascade", target: () => authors }

Revisa el plan antes de aplicarlo — rebase db push imprime las sentencias.

25. El mínimo de Node es >=22.22.0

En 0.17.3 todos los paquetes publicados declaraban >=20 —@rebasepro/cli no declaraba engines en absoluto— y en main todos declaran >=22.22.0. La única fuente es el .nvmrc del repositorio.

Qué cambiar: pásate a Node 22.22.0 antes de actualizar. pnpm install responde a un desajuste de engines con [WARN] Unsupported engine e instala igualmente, así que el fallo no llega al instalar: llega más tarde, en un sitio donde no se menciona Node.

26. rebase.data ya no existe en tiempo de ejecución

RebaseServerClient quitó data de su tipo para que el código de servidor tenga que decir bajo qué identidad corre una lectura, y la propiedad quedó luego en el objeto como alias en tiempo de ejecución. Ahora se borra en el arranque: rebase.data es undefined.

Qué cambiar: en el código de servidor —funciones, crons, callbacks— escribe rebase.dataAsAdmin donde quieras el plano de administración y context.data donde quieras el del llamante. El código tipado ya recibía el error desde que cambió el tipo; lo que se rompe ahora es el código sin tipos, y el ai-instructions.md del andamiaje, que todavía le dice a un asistente que use rebase.data.<slug>. Ese archivo lo escribe rebase init: regenéralo o corrige la regla a mano. El código de navegador no cambia: rebase.data en el SDK cliente es el plano del usuario y se queda.

27. @rebasepro/cli publica tres exports

src/index.ts reexportaba dieciséis módulos y ponía 95 nombres en npm. Ahora exporta entry, manifest y bundle.

Qué cambiar: nada, salvo que importes de @rebasepro/cli —cosa improbable, porque no lo hacía ni este repositorio ni el plano de control—. Si lo haces: la CLI es un binario. Llama a rebase <command> como proceso en lugar de importar sus funciones de comando, cuyas firmas nunca fueron un contrato.

28. Los rangos de peers son carets

ui, forms, firebase, plugin-insights y cms-types declaraban react >=19.0.0, un rango cuya mitad inferior no puede satisfacer a app y cms en 19.2.7: un instalador que eligiera 19.0.0 producía un árbol que resolvía limpio y rompía al renderizar. Los cinco dicen ^19.2.7. El peer typescript de @rebasepro/app pasa de >=5.0.0 a ^6.0.0.

Qué cambiar: estar en React 19.2.7 o posterior, y en TypeScript 6 si usas el plugin de Vite de @rebasepro/app. Si tu instalación resolvía React 19.0.x, verás un aviso de peer hasta que subas; ese aviso es el árbol que ya estabas ejecutando, dicho en voz alta.

29. rebase cloud webhooks create toma --endpoint

--url nombra el plano de control en toda esta familia de comandos, así que el segundo --url que este declaraba para el endpoint del cliente nunca podía ganar: el ejemplo documentado enviaba la URL del webhook al cliente como el host contra el que autenticarse.

Qué cambiar: rebase cloud webhooks create --endpoint https://… en cualquier script que cree uno. La grafía antigua no podía funcionar, así que no hay comportamiento que preservar: solo líneas que corregir.

30. serializeFilter emite de forma estricta

El codificador de hojas compartido parsea con manga ancha, porque un código corto llega por el cable, y emite estricto, porque quien se lo pasa al serializador ha construido la condición a mano. serializeFilter({ a: ["gt", 5] }) lanza en vez de devolver gte.

Qué cambiar: solo si llamas directamente a los serializadores de @rebasepro/common. Usa los nombres de operador que declaran los tipos (gt, gte, lt, lte, …) en lugar de los códigos cortos de REST. Los constructores de consultas y el SDK ya los escribían así; lo nuevo es que la grafía equivocada ahora lo dice.

---

Siguiente: Qué salto te toca · Changelog.