Prisma 8 RC: o que um ORM em pré-release exige do seu plano de upgrade

Desenvolvimento Web · "Loop"

Um major de ORM nunca é só trocar uma dependência. Ele fica entre seu código e o banco, participa de migrations, configurações de ambiente e rotinas de deploy. No Prisma 8 RC, essa proximidade ficou ainda mais evidente: a release candidate 4 encerra fallbacks de configuração e consolida o caminho em torno da CLI unificada.

O primeiro ponto é simples: RC não é recomendação de corte para produção. A própria documentação posiciona Prisma 8 como a próxima geração, enquanto Prisma 7 continua sendo a opção para quem precisa da versão geralmente disponível. Isso não torna a RC irrelevante. Torna o ambiente de teste o lugar certo para descobrir o tamanho real da futura migração.

O fallback deixou de existir

A RC 4 deixa de aceitar prisma-next.config.ts e a forma plana de configuração. Projetos anteriores à RC 2 precisam migrar para prisma.config.ts e para a estrutura encapsulada com definePrismaConfig(). A intenção é reduzir duas formas concorrentes de fazer a mesma coisa, mas a consequência prática é uma falha explícita para quem deixar o arquivo antigo no repositório.

import 'dotenv/config';
import { definePrismaConfig } from '@prisma/cli-engine';
import { defineConfig as ormConfig } from '@prisma/orm-postgres/config';

export default definePrismaConfig({
  orm: ormConfig({
    contract: './contract.prisma',
    db: { connection: process.env['DATABASE_URL']! },
  }),
});

O código acima é representativo da nova configuração de Postgres mostrada nas notas da release. Não copie sem conferir o conector e a versão instalados no projeto. Em pré-release, esse detalhe importa ainda mais: o contrato pode mudar antes do GA e uma receita correta para RC 4 pode não ser a forma final.

Como testar sem transformar o banco em laboratório

  • Crie uma branch e um banco descartável com dados representativos.
  • Fixe a versão exata da RC; não use uma faixa solta em pré-release.
  • Valide geração de artefatos, migrations, consultas críticas e o pipeline de CI.
  • Faça dry run de qualquer alteração de esquema e mantenha rollback independente do ORM.
  • Documente os arquivos e comandos que mudaram para repetir o teste na próxima RC.

Prisma 8 também apresenta uma CLI unificada para seus fluxos de dados. Esse tipo de consolidação pode melhorar a experiência no longo prazo, mas é justamente onde scripts de automação e imagens de CI costumam guardar nomes antigos. Procure referências a binários e arquivos de configuração antes de concluir que o upgrade é só um ajuste no lockfile.

A boa migração de ORM não é a mais rápida, é a que permite comparar o comportamento antes e depois. Se a RC encontrar uma incompatibilidade agora, ela cumpriu o trabalho dela. O bug barato é aquele que morreu no banco temporário, não o que ganhou um ticket de incidente depois da publicação.

Fontes