Upgrade von 0.17 auf 0.18

Upgrade 0.17 → 0.18

0.18.0 ist veröffentlicht. Dies sind die ### Breaking-Einträge aus seinem Abschnitt im Changelog, einer nach dem anderen, jeweils mit dem, was Sie ändern müssen. Unter 0.x ist die Minor-Version die Stelle für Breaking Changes, dies ist also die Grenze zwischen 0.17.3 und 0.18.0 — lesen Sie es, bevor Sie wechseln, nicht danach.

20. defineCollection hat eine einzige Signatur

Aus drei Überladungen (Postgres, Firestore, MongoDB) wurde eine, unterschieden über engine (Postgres, wenn nicht angegeben).

Zu ändern: nichts an einem Aufruf, der bereits kompilierte — nur die Fehlermeldungen landen jetzt auf dem falschen Schlüssel statt auf defineCollection(. UnknownPropertyKey heißt jetzt NoSuchKey; nur Code, der den alten Namen importiert hat, muss angepasst werden.

21. defineCollection prüft nach der ersten fehlerhaften Property weiter

Eine einzige fehlerhafte Property ließ den abgeleiteten Entity-Typ auf Record<string, unknown> zusammenfallen und schaltete jede weitere Prüfung ab.

Zu ändern: nichts zu schreiben, aber rechnen Sie mit neuen Fehlern in Collection-Dateien, die vorher kompilierten. Sie waren schon damals falsch — der Compiler hatte nur aufgehört hinzusehen.

22. Das Verknüpfungsfeld einer Relation muss zu ihrer kind gehören

{ kind: "belongsTo", foreignKeyOnTarget: … } kompiliert nicht mehr.

Zu ändern: Schreiben Sie das Feld, das die Art besitzt.

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

Der Boot-Validator hat das ohnehin schon abgelehnt: Wenn Ihr Projekt heute startet, kompiliert es auch heute.

23. Die validation einer Relation wandert auf die Property

RelationBase.validation und ResolvedRelationBase.validation sind entfernt.

Zu ändern: Verschieben Sie den Eintrag eine Ebene nach oben.

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

Der Boot-Vorgang lehnt den alten Schlüssel namentlich ab. Code, der eine Relation gefragt hat, ob sie erforderlich ist, fragt nun import { isRelationRequired, relationDeclaringProperty } from "@rebasepro/common".

24. Ein erforderliches belongsTo löscht mit RESTRICT, nicht CASCADE

Das ist eine DDL-Änderung. Der nächste rebase db push plant für jede erforderliche Relation ohne ausdrückliches onDelete einen Constraint-Umbau, und danach schlagen Löschvorgänge am Elternobjekt fehl, wo sie vorher kaskadierten.

Zu ändern: Wenn Sie das alte Verhalten behalten wollen, schreiben Sie es hin.

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

Prüfen Sie danach den Plan, bevor Sie ihn anwenden — rebase db push gibt die Anweisungen aus.

25. Die Node-Untergrenze ist >=22.22.0

In 0.17.3 deklarierte jedes veröffentlichte Paket >=20 — @rebasepro/cli gar kein engines —, auf main deklarieren alle >=22.22.0. Die einzige Quelle ist die .nvmrc des Repositorys.

Zu ändern: Wechseln Sie vor dem Upgrade auf Node 22.22.0. pnpm install antwortet auf eine nicht passende Engine mit [WARN] Unsupported engine und installiert trotzdem — der Fehler kommt also nicht bei der Installation, sondern später, an einer Stelle, an der von Node keine Rede ist.

26. rebase.data ist zur Laufzeit verschwunden

RebaseServerClient hat data aus seinem Typ entfernt, damit serverseitiger Code sagen muss, unter wessen Identität ein Lesevorgang läuft — als Laufzeit-Alias blieb die Eigenschaft danach am Objekt. Sie wird beim Boot gelöscht: rebase.data ist undefined.

Zu ändern: In Servercode — Functions, Crons, Callbacks — rebase.dataAsAdmin schreiben, wo die Admin-Ebene gemeint ist, und context.data, wo die des Aufrufers gemeint ist. Typisierter Code bekam den Fehler schon mit der Typänderung; was jetzt bricht, ist untypisierter Code — und die ai-instructions.md eines Scaffolds, die einem Assistenten weiterhin rebase.data.<slug> nahelegt. rebase init schreibt diese Datei, also neu erzeugen oder die Regel von Hand korrigieren. Browsercode bleibt unberührt: rebase.data im Client-SDK ist die nutzergebundene Ebene und bleibt.

27. @rebasepro/cli veröffentlicht drei Exporte

src/index.ts reexportierte sechzehn Module und stellte 95 Namen auf npm. Jetzt sind es entry, manifest und bundle.

Zu ändern: nichts, außer Sie importieren aus @rebasepro/cli — was unwahrscheinlich ist, da weder dieses Repository noch die Control Plane das taten. Falls doch: Die CLI ist eine Binärdatei. Rufen Sie rebase <command> als Prozess auf, statt ihre Kommandofunktionen zu importieren, deren Signaturen nie ein Vertrag waren.

28. Peer-Bereiche sind Carets

ui, forms, firebase, plugin-insights und cms-types deklarierten react >=19.0.0 — ein Bereich, dessen untere Hälfte app und cms bei 19.2.7 nicht erfüllen kann. Ein Installer, der 19.0.0 wählte, erzeugte einen Baum, der sauber auflöste und beim Rendern brach. Alle fünf sagen jetzt ^19.2.7. Der typescript-Peer von @rebasepro/app geht von >=5.0.0 auf ^6.0.0.

Zu ändern: Auf React 19.2.7 oder neuer sein, und auf TypeScript 6, wenn Sie das Vite-Plugin von @rebasepro/app nutzen. Löste Ihre Installation vorher React 19.0.x auf, sehen Sie jetzt eine Peer-Warnung, bis Sie anheben — diese Warnung ist der Baum, den Sie ohnehin schon ausgeführt haben, laut ausgesprochen.

29. rebase cloud webhooks create nimmt --endpoint

--url benennt in dieser Befehlsfamilie die Control Plane, deshalb konnte das zweite --url, das dieser Befehl für den Endpunkt des Kunden deklarierte, nie gewinnen: Das dokumentierte Beispiel schickte die Webhook-URL an den Client als Host, gegen den er sich authentifizieren sollte.

Zu ändern: rebase cloud webhooks create --endpoint https://… in jedem Skript, das einen anlegt. Die alte Schreibweise konnte nicht funktionieren — es gibt also kein Verhalten zu bewahren, nur Zeilen zu korrigieren.

30. serializeFilter schreibt strikt

Der gemeinsame Leaf-Encoder parst großzügig, weil ein Kurzcode von der Leitung kommt, und schreibt strikt, weil ein Aufrufer, der ihn dem Serialisierer übergibt, die Bedingung von Hand gebaut hat. serializeFilter({ a: ["gt", 5] }) wirft, statt gte zurückzuliefern.

Zu ändern: nur, wenn Sie die Serialisierer von @rebasepro/common direkt aufrufen. Verwenden Sie die Operatornamen, die die Typen deklarieren (gt, gte, lt, lte, …), statt REST-Kurzcodes. Query Builder und SDK schrieben sie ohnehin schon so; neu ist, dass die falsche Schreibweise das jetzt sagt.

---

Weiter: Welcher Sprung · Changelog.