Pular para o conteúdo

Atualizar de 0.17 para 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.

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.

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.

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.

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.

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.


A seguir: Que salto · Changelog.