Migrer de 0.17 vers 0.18

Migrer 0.17 → 0.18

La 0.18.0 est publiée. Ce sont les entrées ### Breaking de sa section du changelog, une par une, avec ce que chacune vous demande de modifier. En 0.x, c’est la version mineure qui casse : voici donc le mur entre la 0.17.3 et la 0.18.0 — lisez-le avant de migrer, pas après.

20. defineCollection n’a plus qu’une signature

C’étaient trois surcharges — Postgres, Firestore, MongoDB — et il n’y en a plus qu’une, discriminée par engine (Postgres par défaut).

À changer : rien dans un appel qui compilait déjà ; ce qui change, c’est où l’erreur tombe : sur la clé fautive, et non sur defineCollection(. UnknownPropertyKey s’appelle maintenant NoSuchKey : seul le code qui importait l’ancien nom a une modification à faire.

21. defineCollection continue de vérifier après la première propriété fautive

Une seule propriété erronée faisait s’effondrer l’entité inférée en Record<string, unknown> et désactivait toutes les autres vérifications.

À changer : rien à écrire, mais attendez-vous à de nouvelles erreurs dans des fichiers de collection qui compilaient auparavant. Ils étaient déjà faux ; le compilateur avait cessé de regarder.

22. Le champ de lien d’une relation doit appartenir à son kind

{ kind: "belongsTo", foreignKeyOnTarget: … } ne compile plus.

À changer : écrivez le champ que la sorte de relation possède.

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

Le validateur de démarrage les refusait déjà : si votre projet démarre aujourd’hui, il compile aujourd’hui.

23. La validation d’une relation remonte sur la propriété

RelationBase.validation et ResolvedRelationBase.validation sont supprimés.

À changer : remontez-la d’un niveau, à côté de celle de tous les autres champs.

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

Le démarrage refuse l’ancienne clé en la nommant. Le code qui demandait à une relation si elle était obligatoire utilise désormais import { isRelationRequired, relationDeclaringProperty } from "@rebasepro/common".

24. Un belongsTo obligatoire supprime en RESTRICT, pas en CASCADE

C’est un changement de DDL. Le prochain rebase db push planifie une reconstruction de contrainte pour chaque relation obligatoire qui n’a jamais nommé d’onDelete, et après cela les suppressions du parent échouent là où elles cascadaient.

À changer : pour conserver l’ancien comportement, écrivez-le.

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

Relisez le plan avant de l’appliquer — rebase db push affiche les instructions.

25. Le plancher Node est >=22.22.0

En 0.17.3 chaque paquet publié déclarait >=20 — @rebasepro/cli ne déclarait aucun engines — et sur main tous déclarent >=22.22.0. La source unique est le .nvmrc du dépôt.

À changer : passez à Node 22.22.0 avant de mettre à niveau. pnpm install répond à une incompatibilité d’engines par [WARN] Unsupported engine et installe quand même : l’échec n’arrive donc pas à l’installation, mais plus tard, à un endroit où Node n’est jamais mentionné.

26. rebase.data a disparu à l’exécution

RebaseServerClient a retiré data de son type pour que le code serveur doive dire sous quelle identité tourne une lecture — la propriété était ensuite restée sur l’objet comme alias d’exécution. Elle est supprimée au démarrage : rebase.data vaut undefined.

À changer : dans le code serveur — fonctions, crons, callbacks — écrivez rebase.dataAsAdmin là où vous voulez le plan administrateur et context.data là où vous voulez celui de l’appelant. Le code typé recevait l’erreur depuis le changement de type ; ce qui casse maintenant, c’est le code non typé, et le ai-instructions.md d’un échafaudage, qui indique encore à un assistant d’utiliser rebase.data.<slug>. Ce fichier est écrit par rebase init : régénérez-le ou corrigez la règle à la main. Le code navigateur est intact : rebase.data dans le SDK client est le plan utilisateur et reste.

27. @rebasepro/cli publie trois exports

src/index.ts réexportait seize modules et plaçait 95 noms sur npm. Il exporte maintenant entry, manifest et bundle.

À changer : rien, sauf si vous importez depuis @rebasepro/cli — ce qui est peu probable, puisque ni ce dépôt ni le plan de contrôle ne le faisaient. Si oui : la CLI est un binaire. Appelez rebase <command> comme processus plutôt que d’importer ses fonctions de commande, dont les signatures n’ont jamais été un contrat.

28. Les plages de peers sont des carets

ui, forms, firebase, plugin-insights et cms-types déclaraient react >=19.0.0, une plage dont la moitié basse ne peut pas satisfaire app et cms en 19.2.7 : un installeur choisissant 19.0.0 produisait un arbre qui se résolvait proprement et cassait au rendu. Les cinq disent ^19.2.7. Le peer typescript de @rebasepro/app passe de >=5.0.0 à ^6.0.0.

À changer : être en React 19.2.7 ou plus, et en TypeScript 6 si vous utilisez le plugin Vite de @rebasepro/app. Si votre installation résolvait React 19.0.x, vous verrez un avertissement de peer jusqu’à ce que vous montiez ; cet avertissement, c’est l’arbre que vous exécutiez déjà, dit à voix haute.

29. rebase cloud webhooks create prend --endpoint

--url nomme le plan de contrôle pour toute cette famille de commandes, donc le second --url que celle-ci déclarait pour l’endpoint du client ne pouvait jamais l’emporter : l’exemple documenté envoyait l’URL du webhook au client comme hôte d’authentification.

À changer : rebase cloud webhooks create --endpoint https://… dans tout script qui en crée un. L’ancienne graphie ne pouvait pas fonctionner : il n’y a pas de comportement à préserver, seulement des lignes à corriger.

30. serializeFilter émet strictement

L’encodeur de feuilles partagé analyse largement, parce qu’un code court arrive du réseau, et émet strictement, parce qu’un appelant qui en passe un au sérialiseur a construit la condition à la main. serializeFilter({ a: ["gt", 5] }) lève au lieu de renvoyer gte.

À changer : seulement si vous appelez directement les sérialiseurs de @rebasepro/common. Utilisez les noms d’opérateurs que déclarent les types (gt, gte, lt, lte, …) plutôt que les codes courts REST. Les constructeurs de requêtes et le SDK les écrivaient déjà ainsi ; ce qui change, c’est que la mauvaise graphie le dit maintenant.

---

Ensuite : Quel saut · Changelog.