Webpack → Vite: la historia de una migración de bundler
(engineering.ab180.co)Comparto la experiencia de migrar de Webpack a Vite, que habíamos usado durante 5 años desde el lanzamiento del servicio. Tiene muchas partes imperfectas, pero agradecería que lo leyeran con gusto.
Ventajas de Webpack y cambios en el ecosistema web
Webpack se ha desarrollado y mantenido durante los últimos 10 años, y cuenta con un ecosistema bien establecido.
También se usa ampliamente en muchos lugares, como Create React App, y agrupa módulos con el enfoque IIFE para dar soporte a varios navegadores.
Sin embargo, durante 5 años, las funcionalidades del servicio crecieron casi 3 veces, lo que aumentó los tiempos de build y empeoró la experiencia de desarrollo. Además, con la evolución del ecosistema web hubo varios cambios, como el soporte para ES Module.
Bundler + Native
En los últimos 1 o 2 años, empezó a ganar fuerza la idea de hacer bundling y transpiling apoyándose en Native. Se intentó superar los límites de procesamiento de JS, que es single-threaded.
Entre los ejemplos representativos están esbuild, basado en Golang, y SWC, basado en Rust.
Primer intento: bundling usando solo esbuild
En ese momento, considerando la estabilidad y el ecosistema, incluidos los plugins, se decidió usar un bundler basado en esbuild. Y también queríamos medir qué tanto rendimiento ofrecía esbuild por sí mismo.
Después de instalar el paquete y ejecutar el script de build, una compilación que antes tardaba unos 210 segundos terminó en solo 2.16 segundos. Mostró una velocidad de build unas 100 veces más rápida.
Pero al aplicar Babel para usar EmotionJS, se volvió 10 veces más lento.
Además, como esbuild no soportaba HMR, se concluyó que sería difícil usarlo. Se podía implementar HMR directamente, pero se consideró que requeriría demasiado esfuerzo y altos costos de mantenimiento, soporte y gestión.
Segundo intento: bundling con Vite
El concepto de Vite es separar Dependencies y Source code.
Las Dependencies no cambian después de instalarse, así que se transpilan por adelantado con esbuild. El Source code cambia con frecuencia, así que se carga con ESM. Los resultados del build se almacenan en caché para permitir builds de desarrollo rápidos.
La migración avanzó fácilmente usando la plantilla que ofrece Vite. Hubo algunos issues, pero se resolvieron rápido, y fue posible tener una configuración mucho más corta y simple que con Webpack.
Resultado de la migración del bundler
Al medir el tiempo de build en Netlify, pasó de un promedio de 250 segundos a un promedio de 90 segundos. Se redujo a 36% del nivel anterior.
Como el archivo de configuración se volvió más simple, los miembros del equipo pudieron crear fácilmente entornos de build personalizados aprovechándolo, lo que mejoró la eficiencia.
Para seguir mejorando, se puede cambiar a una librería CSS-in-JS sin dependencia de Babel y probar la adopción de Monorepo.
En cuanto al ecosistema, si SWC se estabiliza, podría reemplazar a Babel, y TypeScript Type Checker también está siendo porteado a Native.
Lecciones
- Incluso un trabajo que parecía grande se resuelve fácilmente si se divide en partes pequeñas, se prueba y se discute bastante.
- Incluso las herramientas que hoy se usan de forma mayoritaria pueden desaparecer rápido con la evolución del ecosistema.
- Una buena accesibilidad crea un buen entorno.
3 comentarios
La velocidad de esbuild es impresionante.
Yo también dudaba un poco cuando vi que en la página principal de esbuild presumían que era entre 10 y 100 veces más rápido, pero al verlo en la práctica, ¡de verdad me impactó!
¡Yo también espero con muchas ganas que llegue esa época! Creo que de verdad va a hacer que desarrollar sea mucho más agradable :)