Atualizar de 0.17 para 0.18
Atualizar 0.17 → 0.18
Seção intitulada “Atualizar 0.17 → 0.18”A 0.18.0 está publicada. São as entradas ### Breaking da sua
secção do changelog, uma de cada vez, com o que cada uma
lhe pede para alterar. Em 0.x é a versão menor que quebra, portanto este é o muro
entre a 0.17.3 e a 0.18.0 — leia-o antes de atualizar, não depois.
20. defineCollection tem uma única assinatura
Seção intitulada “20. defineCollection tem uma única assinatura”Eram três sobrecargas — Postgres, Firestore, MongoDB — e agora é uma só,
discriminada por engine (Postgres quando ausente).
O que mudar: nada numa chamada que já compilava; o que muda é onde o erro cai,
agora sobre a chave errada e não sobre defineCollection(. UnknownPropertyKey
passa a chamar-se NoSuchKey: só o código que importava o nome antigo tem algo a
alterar.
21. defineCollection continua a verificar depois da primeira propriedade errada
Seção intitulada “21. defineCollection continua a verificar depois da primeira propriedade errada”Uma única propriedade errada colapsava a entidade inferida para
Record<string, unknown> e desligava todas as outras verificações.
O que mudar: nada a escrever, mas conte com erros novos em ficheiros de coleção que antes compilavam. Já estavam errados; o compilador é que tinha deixado de olhar.
22. O campo de ligação de uma relação tem de pertencer ao seu kind
Seção intitulada “22. O campo de ligação de uma relação tem de pertencer ao seu kind”{ kind: "belongsTo", foreignKeyOnTarget: … } já não compila.
O que mudar: escreva o campo que aquele tipo de relação possui.
author: { type: "relation", relation: { kind: "belongsTo", foreignKeyOnTarget: "author_id", target: () => authors } relation: { kind: "belongsTo", localKey: "author_id", target: () => authors }}O validador de arranque já as recusava: se o seu projeto arranca hoje, compila hoje.
23. A validation de uma relação sobe para a propriedade
Seção intitulada “23. A validation de uma relação sobe para a propriedade”RelationBase.validation e ResolvedRelationBase.validation foram removidos.
O que mudar: suba-a um nível, ao lado da de qualquer outro campo.
author: { type: "relation", validation: { required: true }, relation: { kind: "belongsTo", validation: { required: true }, target: () => authors } relation: { kind: "belongsTo", target: () => authors }}O arranque recusa a chave antiga pelo nome. O código que perguntava a uma relação
se era obrigatória usa agora
import { isRelationRequired, relationDeclaringProperty } from "@rebasepro/common".
24. Um belongsTo obrigatório apaga com RESTRICT, não com CASCADE
Seção intitulada “24. Um belongsTo obrigatório apaga com RESTRICT, não com CASCADE”Isto é uma alteração de DDL. O próximo rebase db push planeia uma
reconstrução da restrição para cada relação obrigatória que nunca indicou um
onDelete, e depois disso as eliminações do pai começam a falhar onde antes
faziam cascata.
O que mudar: para manter o comportamento anterior, escreva-o.
relation: { kind: "belongsTo", target: () => authors }relation: { kind: "belongsTo", onDelete: "cascade", target: () => authors }Depois leia o plano antes de o aplicar — rebase db push imprime as instruções.
25. O mínimo de Node é >=22.22.0
Seção intitulada “25. O mínimo de Node é >=22.22.0”Em 0.17.3 todos os pacotes publicados declaravam >=20 — o @rebasepro/cli não
declarava engines de todo — e em main todos declaram >=22.22.0. A única
fonte é o .nvmrc do repositório.
O que mudar: passe para o Node 22.22.0 antes de atualizar. O pnpm install
responde a um desencontro de engines com [WARN] Unsupported engine e instala à
mesma, por isso a falha não chega na instalação: chega mais tarde, num sítio onde
o Node nunca é mencionado.
26. rebase.data deixou de existir em tempo de execução
Seção intitulada “26. rebase.data deixou de existir em tempo de execução”O RebaseServerClient retirou data do seu tipo para que o código de servidor
tenha de dizer sob que identidade corre uma leitura, e a propriedade ficou depois
no objeto como alias em tempo de execução. Agora é apagada no arranque:
rebase.data é undefined.
O que mudar: no código de servidor — funções, crons, callbacks — escreve
rebase.dataAsAdmin onde queres o plano de administração e context.data onde
queres o de quem chama. O código tipado já recebia o erro desde que o tipo mudou;
o que parte agora é o código sem tipos, e o ai-instructions.md do andaime, que
ainda diz a um assistente para usar rebase.data.<slug>. Esse ficheiro é escrito
pelo rebase init: regenera-o ou corrige a regra à mão. O código de browser fica
intacto: rebase.data no SDK cliente é o plano do utilizador e mantém-se.
27. @rebasepro/cli publica três exports
Seção intitulada “27. @rebasepro/cli publica três exports”O src/index.ts reexportava dezasseis módulos e punha 95 nomes no npm. Agora
exporta entry, manifest e bundle.
O que mudar: nada, a não ser que importes de @rebasepro/cli — o que é
improvável, já que nem este repositório nem o control plane o faziam. Se o fazes:
a CLI é um binário. Chama rebase <command> como processo em vez de importar as
suas funções de comando, cujas assinaturas nunca foram um contrato.
28. Os intervalos de peers são carets
Seção intitulada “28. Os intervalos de peers são carets”ui, forms, firebase, plugin-insights e cms-types declaravam
react >=19.0.0, um intervalo cuja metade inferior não consegue satisfazer app
e cms em 19.2.7: um instalador que escolhesse 19.0.0 produzia uma árvore que
resolvia limpa e partia no render. Os cinco dizem ^19.2.7. O peer typescript
de @rebasepro/app passa de >=5.0.0 para ^6.0.0.
O que mudar: estar em React 19.2.7 ou posterior, e em TypeScript 6 se usares
o plugin Vite do @rebasepro/app. Se a tua instalação resolvia React 19.0.x vais
ver um aviso de peer até subires; esse aviso é a árvore que já estavas a correr,
dita em voz alta.
29. rebase cloud webhooks create recebe --endpoint
Seção intitulada “29. rebase cloud webhooks create recebe --endpoint”O --url nomeia o control plane em toda esta família de comandos, por isso o
segundo --url que este declarava para o endpoint do cliente nunca podia ganhar:
o exemplo documentado enviava o URL do webhook ao cliente como o host contra o
qual autenticar-se.
O que mudar: rebase cloud webhooks create --endpoint https://… em qualquer
script que crie um. A grafia antiga não podia funcionar, por isso não há
comportamento a preservar: só linhas a corrigir.
30. serializeFilter emite de forma estrita
Seção intitulada “30. serializeFilter emite de forma estrita”O leaf encoder partilhado analisa com folga, porque um short code chega pela
rede, e emite estrito, porque quem o passa ao serializador construiu a condição à
mão. serializeFilter({ a: ["gt", 5] }) lança em vez de devolver gte.
O que mudar: só se chamares diretamente os serializadores de
@rebasepro/common. Usa os nomes de operador que os tipos declaram (gt, gte,
lt, lte, …) em vez dos short codes REST. Os query builders e o SDK já os
escreviam assim; o que muda é que a grafia errada passa a dizê-lo.