Webpack → Vite: a história de uma migração de bundler
(engineering.ab180.co)Compartilho aqui a experiência de migrar do Webpack para o Vite depois de 5 anos de uso desde o lançamento do serviço. Ainda há muitos pontos que poderiam ser melhores, mas ficarei feliz se vocês lerem e se divertirem.
Vantagens do Webpack e mudanças no ecossistema web
O Webpack foi desenvolvido e mantido ao longo dos últimos 10 anos, e conta com um ecossistema bem estabelecido.
Também é usado em muitos lugares, como o Create React App, e agrupa módulos no formato IIFE para oferecer suporte a vários navegadores.
No entanto, ao longo de 5 anos, as funcionalidades do serviço quase triplicaram, o que aumentou o tempo de build e piorou a experiência de desenvolvimento. Além disso, com a evolução do ecossistema web, houve várias mudanças, como o suporte a ES Module.
Bundler + Native
Nos últimos 1 a 2 anos, começou a ganhar força a ideia de fazer bundling e transpiling com a ajuda do Native. Foram feitas tentativas para superar os limites de processamento do JS, que é single-thread.
Alguns exemplos representativos são o esbuild, baseado em Golang, e o SWC, baseado em Rust.
Primeira tentativa: bundling usando apenas esbuild
Na época, considerando estabilidade, plugins e o ecossistema, decidiu-se usar um bundler baseado em esbuild. E também queríamos verificar qual era, de fato, o nível de desempenho do próprio esbuild.
Depois de instalar o pacote e rodar o script de build, um processo que antes levava cerca de 210 segundos terminou em apenas 2,16 segundos. Isso mostrou uma velocidade de build cerca de 100 vezes maior.
Mas, ao aplicar Babel para usar EmotionJS, a velocidade caiu 10 vezes.
Além disso, como o esbuild não suportava HMR, concluímos que seria difícil utilizá-lo. Até seria possível implementar HMR diretamente, mas acreditamos que o custo de esforço, manutenção e operação seria muito alto.
Segunda tentativa: bundling com Vite
O conceito do Vite é separar Dependencies e Source code.
As Dependencies não mudam após a instalação, então são transpiled antecipadamente com esbuild. Já o Source code muda com frequência, então é carregado como ESM. Os resultados de build são armazenados em cache, o que permite builds de desenvolvimento rápidos.
Usando o template fornecido pelo Vite, a migração foi feita com facilidade. Houve alguns problemas, mas foram resolvidos rapidamente, e passamos a ter uma configuração muito mais curta e simples do que no Webpack.
Resultado da migração de bundler
Ao medir o tempo de build no Netlify, a média caiu de 250 segundos para 90 segundos. Houve uma redução para 36% do nível anterior.
Como o arquivo de configuração ficou mais simples, os membros da equipe conseguiram criar com facilidade ambientes de build customizados usando isso, o que aumentou a produtividade.
Para melhorar ainda mais, é possível trocar por uma biblioteca CSS-in-JS sem dependência de Babel e aplicar Monorepo.
No ecossistema, se o SWC se estabilizar, ele poderá substituir o Babel, e o TypeScript Type Checker também está sendo portado para Native.
Lições aprendidas
- Mesmo trabalhos que parecem grandes ficam mais fáceis quando são divididos em partes menores, testados e amplamente discutidos.
- Até ferramentas que hoje são amplamente usadas podem desaparecer rapidamente com a evolução do ecossistema.
- Uma boa acessibilidade cria um bom ambiente.
3 comentários
A velocidade do esbuild é impressionante.
Eu ficava meio desconfiado ao ver até na página principal do esbuild eles destacando que era de 10 a 100x mais rápido, mas quando vi na prática, foi chocante mesmo!
Eu também estou muito ansioso para que uma era assim chegue! Acho que vai ficar muito melhor para desenvolver :)