Salta ai contenuti

Aggiornare da 0.17 a 0.18

La 0.18.0 è pubblicata. Sono le voci ### Breaking della sua sezione del changelog, una alla volta, con ciò che ciascuna ti chiede di modificare. In 0.x è la minor a rompere, quindi questo è il muro tra la 0.17.3 e la 0.18.0: leggilo prima di aggiornare, non dopo.

Erano tre overload — Postgres, Firestore, MongoDB — e ora è una sola, discriminata su engine (Postgres quando manca).

Cosa cambiare: nulla in una chiamata che già compilava; cambia dove atterra l’errore, ora sulla chiave sbagliata e non su defineCollection(. UnknownPropertyKey ora si chiama NoSuchKey: solo il codice che importava il vecchio nome ha qualcosa da modificare.

21. defineCollection continua a controllare dopo la prima proprietà errata

Sezione intitolata “21. defineCollection continua a controllare dopo la prima proprietà errata”

Una sola proprietà sbagliata faceva collassare l’entità inferita a Record<string, unknown> e spegneva ogni altro controllo.

Cosa cambiare: niente da scrivere, ma aspettati errori nuovi in file di collection che prima compilavano. Erano già sbagliati allora; il compilatore aveva smesso di guardare.

22. Il campo di collegamento di una relazione deve appartenere al suo kind

Sezione intitolata “22. Il campo di collegamento di una relazione deve appartenere al suo kind”

{ kind: "belongsTo", foreignKeyOnTarget: … } non compila più.

Cosa cambiare: scrivi il campo che quel tipo di relazione possiede.

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

Il validatore di avvio le rifiutava già: se il tuo progetto parte oggi, compila oggi.

23. La validation di una relazione sale sulla proprietà

Sezione intitolata “23. La validation di una relazione sale sulla proprietà”

RelationBase.validation e ResolvedRelationBase.validation sono rimossi.

Cosa cambiare: spostala di un livello, accanto a quella di ogni altro campo.

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

L’avvio rifiuta la vecchia chiave per nome. Il codice che chiedeva a una relazione se fosse obbligatoria ora usa import { isRelationRequired, relationDeclaringProperty } from "@rebasepro/common".

24. Un belongsTo obbligatorio cancella con RESTRICT, non CASCADE

Sezione intitolata “24. Un belongsTo obbligatorio cancella con RESTRICT, non CASCADE”

Questa è una modifica DDL. Il prossimo rebase db push pianifica una ricostruzione del vincolo per ogni relazione obbligatoria che non ha mai indicato un onDelete, e dopo di essa le cancellazioni del padre iniziano a fallire dove prima andavano in cascata.

Cosa cambiare: per mantenere il comportamento precedente, scrivilo.

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

Poi rileggi il piano prima di applicarlo — rebase db push stampa le istruzioni.

In 0.17.3 ogni pacchetto pubblicato dichiarava >=20@rebasepro/cli non dichiarava alcun engines — e su main tutti dichiarano >=22.22.0. L’unica fonte è il .nvmrc del repository.

Cosa cambiare: passa a Node 22.22.0 prima di aggiornare. pnpm install risponde a un disallineamento di engines con [WARN] Unsupported engine e installa comunque, quindi l’errore non arriva all’installazione: arriva dopo, in un punto in cui Node non viene mai nominato.

RebaseServerClient ha tolto data dal proprio tipo perché il codice server debba dire sotto quale identità gira una lettura, e la proprietà era poi rimasta sull’oggetto come alias a runtime. Ora viene cancellata al boot: rebase.data è undefined.

Cosa cambiare: nel codice server — funzioni, cron, callback — scrivi rebase.dataAsAdmin dove intendi il piano di amministrazione e context.data dove intendi quello del chiamante. Il codice tipizzato riceveva l’errore già dal cambio di tipo; quello che si rompe adesso è il codice non tipizzato, e l’ai-instructions.md di uno scaffold, che dice ancora a un assistente di usare rebase.data.<slug>. Quel file lo scrive rebase init: rigeneralo o correggi la regola a mano. Il codice browser non cambia: rebase.data nell’SDK client è il piano dell’utente e resta.

src/index.ts riesportava sedici moduli e metteva 95 nomi su npm. Ora esporta entry, manifest e bundle.

Cosa cambiare: nulla, a meno che tu non importi da @rebasepro/cli — cosa improbabile, dato che non lo facevano né questo repository né il control plane. Se lo fai: la CLI è un binario. Invoca rebase <command> come processo invece di importare le sue funzioni di comando, le cui firme non sono mai state un contratto.

ui, forms, firebase, plugin-insights e cms-types dichiaravano react >=19.0.0, un intervallo la cui metà inferiore non può soddisfare app e cms a 19.2.7: un installer che sceglieva 19.0.0 produceva un albero che si risolveva pulito e si rompeva al render. Tutti e cinque dicono ^19.2.7. Il peer typescript di @rebasepro/app passa da >=5.0.0 a ^6.0.0.

Cosa cambiare: stare su React 19.2.7 o successivo, e su TypeScript 6 se usi il plugin Vite di @rebasepro/app. Se la tua installazione risolveva React 19.0.x vedrai un avviso di peer finché non sali; quell’avviso è l’albero che stavi già eseguendo, detto ad alta voce.

29. rebase cloud webhooks create prende --endpoint

Sezione intitolata “29. rebase cloud webhooks create prende --endpoint”

--url nomina il control plane per tutta questa famiglia di comandi, quindi il secondo --url che questo dichiarava per l’endpoint del cliente non poteva mai vincere: l’esempio documentato mandava l’URL del webhook al client come host su cui autenticarsi.

Cosa cambiare: rebase cloud webhooks create --endpoint https://… in ogni script che ne crea uno. La vecchia grafia non poteva funzionare: non c’è comportamento da preservare, solo righe da correggere.

Il leaf encoder condiviso parsifica in modo permissivo, perché uno short code arriva dalla rete, ed emette in modo stretto, perché chi lo passa al serializzatore ha costruito la condizione a mano. serializeFilter({ a: ["gt", 5] }) solleva invece di restituire gte.

Cosa cambiare: solo se chiami direttamente i serializzatori di @rebasepro/common. Usa i nomi di operatore che i tipi dichiarano (gt, gte, lt, lte, …) invece degli short code REST. I query builder e l’SDK li scrivevano già così; la novità è che la grafia sbagliata ora lo dice.


Avanti: Quale salto · Changelog.