Vitest 5 RC: vale testar já ou esperar a versão estável?

Ferramentas · "Loop"

O Vitest 5 ainda é pré-release, e isso deveria aparecer antes de qualquer comando de instalação. A RC 2, publicada em 17 de agosto, melhora pontos concretos como concorrência no ciclo de vida dos testes, falhas no browser mode e o resumo do GitHub Actions. É um bom motivo para testar a migração. Não é motivo para atualizar a branch de produção numa sexta-feira e descobrir a definição de “experimental” no deploy.

O que uma release candidate serve para fazer

RC é ambiente de integração. Ela permite que projetos reais encontrem incompatibilidades antes da versão estável, especialmente em configurações menos óbvias: monorepo, browser tests, providers de cobertura, mocks de módulos e runners de CI. A própria documentação do Vitest deixa claro que pré-releases são instáveis, podem receber breaking changes e devem ser fixadas em versões exatas.

// package.json
{
  "devDependencies": {
    "vitest": "5.0.0-rc.2"
  },
  "scripts": {
    "test:next": "vitest run"
  }
}

O mais útil é criar um job separado, como test:next, e executá-lo em paralelo com a versão estável. Assim o time vê erros e diferenças de comportamento sem transformar cada falha em bloqueio imediato. Quando a RC vira stable, você já tem histórico de compatibilidade, em vez de uma migração cega no dia do anúncio.

O que revisar antes de testar

  • Vitest 5 requer Vite 6.4 ou superior e Node.js 22.12 ou superior.
  • clearMocks passa a ser true por padrão, alterando o histórico observado entre testes.
  • Opções sequenciais antigas e partes da configuração de benchmark foram removidas.
  • Projetos com browser mode devem validar locators, cancelamentos e o encerramento do navegador no CI.

Essas mudanças são exatamente o tipo de coisa que faz uma suíte “passar” e, ainda assim, esconder uma alteração de contrato. Mocks limpos entre testes tendem a melhorar isolamento, mas podem revelar testes que dependiam sem perceber da ordem de execução. É um erro útil, só não é um erro que você quer descobrir junto com uma entrega urgente.

Uma RC não precisa decidir o futuro hoje

Se o projeto é uma biblioteca que integra com Vite ou mantém plugins de teste, testar cedo tem valor direto para o ecossistema. Para uma aplicação comum, o ganho é saber se a migração vai ser tranquila e reportar um problema reproduzível quando não for. O custo aceitável é um job extra; o custo evitado é uma atualização sem diagnóstico no futuro.

Fontes