Vite 8 troca esbuild e Rollup pelo Rolldown, um único bundler em Rust
O Vite 8.0 foi anunciado como versão estável em 12 de março. Deixei passar uma semana antes de escrever porque queria entender o tamanho da mudança, e ela é grande: pela primeira vez, o Vite usa um único bundler para desenvolvimento e produção.
Um bundler só: Rolldown
Desde o início, o Vite viveu com dois motores. O esbuild cuidava do desenvolvimento, e o Rollup, do build de produção. Funcionava, mas significava manter duas pipelines com comportamentos ligeiramente diferentes. O Vite 8 substitui essa dupla pelo Rolldown, um bundler escrito em Rust. Nas palavras do anúncio, os dois caminhos agora “se resolvem em um”.
O argumento principal é velocidade. Segundo a equipe do Vite, o Rolldown entrega builds até 10 a 30 vezes mais rápidos que o Rollup, no mesmo nível do esbuild. O post também cita relatos de empresas que testaram as versões prévias: a Linear teria reduzido o build de produção de 46 para 6 segundos, e Ramp, Mercedes-Benz.io e Beehiiv relataram reduções de 57%, até 38% e 64%, respectivamente. São números dos próprios usuários e da equipe, não medições independentes, mas a ordem de grandeza é consistente.
Migração: mais suave do que parece
A preocupação natural com uma troca de bundler é quebrar configurações e plugins. O Vite 8 traz uma camada de compatibilidade que converte automaticamente as opções esbuild e rollupOptions existentes para os equivalentes no Rolldown e no Oxc. Segundo o anúncio, o Rolldown suporta a mesma API de plugins do Rollup e do Vite, e a maioria dos plugins funciona sem mudanças.
Os requisitos de Node não mudaram em relação ao Vite 7: 20.19+ ou 22.12+. Essas versões suportam require(esm) sem flag, o que permite que o Vite seja distribuído apenas como ESM. Um detalhe que pode importar em ambientes enxutos: o pacote ficou cerca de 15 MB maior, em boa parte por causa do lightningcss, que virou dependência normal, e do próprio Rolldown.
Recursos novos que valem atenção
Além do bundler, a versão traz uma série de melhorias práticas:
- Devtools: a opção
devtoolsativa o Vite Devtools. - Aliases do tsconfig: com
resolve.tsconfigPathsemtrue, o Vite resolve os paths do TypeScript sem plugin externo. Vem desligado por padrão porque tem um pequeno custo de desempenho. - emitDecoratorMetadata: suporte nativo, dispensando plugins de terceiros.
- Wasm no SSR: imports com
.wasm?initagora funcionam na renderização no servidor. - Encaminhamento de console:
server.forwardConsoleenvia logs e erros do console do navegador para o terminal do dev server. E aqui está o detalhe que mais me chamou a atenção: ele liga sozinho quando um agente de código é detectado. - Full Bundle Mode (experimental): empacota os módulos também no desenvolvimento. Resultados preliminares citados pela equipe falam em inicialização 3 vezes mais rápida, recarregamentos completos 40% mais rápidos e 10 vezes menos requisições de rede.
O @vitejs/plugin-react chegou à versão 6, usando Oxc para a transformação do React Refresh. O Babel deixou de ser dependência, o que reduz o tamanho da instalação. Quem quiser o React Compiler ativa explicitamente com o helper reactCompilerPreset, via @rolldown/plugin-babel. A versão 5 do plugin continua funcionando com o Vite 8, então dá para atualizar uma coisa de cada vez.
Por fim, o projeto lançou um registro de plugins em registry.vite.dev, um diretório pesquisável de plugins para Vite, Rolldown e Rollup, alimentado diariamente com dados do npm.
Minha leitura
A unificação em torno do Rolldown é a mudança estrutural mais importante do Vite desde que ele surgiu. Ter o mesmo motor no desenvolvimento e na produção elimina uma fonte antiga de diferenças sutis, e a velocidade vem de brinde. A camada de compatibilidade mostra que a equipe levou a migração a sério.
O que mais me interessa, porém, é o server.forwardConsole ligando automaticamente para agentes de código. É um sinal pequeno, mas revelador: ferramentas de build estão começando a tratar agentes como usuários de primeira classe. Um agente que roda o dev server e não enxerga o console do navegador está trabalhando às cegas, e o Vite resolveu isso por padrão.
Minha recomendação para quem tem projetos em produção é testar a atualização em um branch, comparar o resultado do build e prestar atenção aos plugins menos populares. Para projetos novos, não vejo motivo para começar em outra versão.