Aggiornare da 0.17 a 0.18
Aggiornare 0.17 → 0.18
Sezione intitolata “Aggiornare 0.17 → 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.
20. defineCollection ha una sola firma
Sezione intitolata “20. defineCollection ha una sola firma”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.
25. Il minimo di Node è >=22.22.0
Sezione intitolata “25. Il minimo di Node è >=22.22.0”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.
26. rebase.data non esiste più a runtime
Sezione intitolata “26. rebase.data non esiste più a runtime”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.
27. @rebasepro/cli pubblica tre export
Sezione intitolata “27. @rebasepro/cli pubblica tre export”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.
28. Gli intervalli dei peer sono caret
Sezione intitolata “28. Gli intervalli dei peer sono caret”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.
30. serializeFilter emette in modo stretto
Sezione intitolata “30. serializeFilter emette in modo stretto”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.