Vite 8 fusionó sus herramientas de empaquetado en Rolldown: ¿qué se rompió?
Vite 8 utiliza por defecto el modo Rolldown para entornos de desarrollo y producción. La interoperabilidad real con CJS causa problemas, existen dificultades en la migración de chunks, y es necesario seguir una lista de verificación segura antes de confiar en que el proceso CI esté completo sin errores.
Durante años, Vite ejecutó en secreto dos bundlers diferentes: uno mientras se desarrollaba y otro al desplegar. Rolldown pone fin a esa división. Las mejoras en velocidad son reales, al igual que la lista de problemas que surgen.
Muchos equipos conocen los síntomas sin nombrar la causa: el servidor local muestra estado verde, mientras que en producción es rojo, y la raíz del problema no es un error de escritura. El entorno de ejecución que servía los módulos en desarrollo y la herramienta que los empaquetaba para producción no estaban de acuerdo respecto a un caso límite. En Vite, esa discrepancia era estructural: esbuild se utilizaba durante el desarrollo, Rollup para la producción, y la integración era lo suficientemente buena como para que la diferencia quedara invisible… hasta que dejó de serlo.
Vite 8 elimina esa diferencia con un único bundler en Rust: Rolldown. Los resultados de las pruebas son muy buenos, al igual que el listado de aplicaciones que dejaron de funcionar cuando los problemas derivados de los dos sistemas anteriores ya no tuvieron dónde ocultarse. Conocer ambos lados es la clave para actualizar sin sorpresas indeseadas.
¿Qué cambió en Vite 8?
La estrategia de doble motor era razonable en 2020. Crear un bundler de producción desde cero requiere años de trabajo. esbuild ya se desarrollaba rápidamente; Rollup ya contaba con un ecosistema de plugins. Unirlos era una opción pragmática. Sin embargo, esto generó un riesgo persistente: dos herramientas que interpretaban los mismos archivos de manera diferente, especialmente en lo relacionado con la interoperabilidad de CommonJS, ese puente incómodo entre los módulos require() y el ESM moderno.
Rolldown representa la solución a todo ese problema en un único motor. Implementación en Rust, API de plugins similar a la de Rollup (la mayoría de los plugins siguen funcionando), versión 1.0 estable el 7 de mayo de 2026 con una API fija destinada a entornos de producción. Vite 8 en sí se estabilizó el 12 de marzo de 2026 y estableció a Rolldown como opción predeterminada sin necesidad de activación adicional. Las tareas de transformación y minificación que antes se realizaban con esbuild ahora se hacen con Oxc, otra herramienta en Rust desarrollada por VoidZero (la misma organización detrás de Rolldown).
Título: las compilaciones de producción pueden realizarse 10–30 veces más rápido que Rollup clásico. El modo de desarrollo es la historia menos conocida. El “modo de paquete completo” empaqueta la aplicación en modo desarrollo de la misma manera que lo hace producción, en lugar de servir ESM por archivo sin procesar. Las primeras pruebas indican un inicio en frío aproximadamente 3 veces más rápido, recargas completas unas 40% más rápidas y unas 10 veces menos solicitudes de red. Los grandes conjuntos de código ya habían superado las limitaciones del ESM sin empaquetar en el desarrollo; esto cierra esa brecha.
La ventaja estructural es más simple: un único motor para ambos modos. Los antiguos errores del tipo “interoperabilidad en desarrollo ≠ interoperabilidad en producción” se vuelven imposibles, ya que no queda otro empaquetador con el cual discrepar.
Qué realmente falló
La migración no fue gratuita, y minimizar ese hecho no ayuda a quienes planean una actualización.
La interoperabilidad más estricta de CommonJS dañó los paquetes. Las exportaciones ambiguas en CJS se manejan de manera diferente al antiguo par esbuild+Rollup. Sin module.exports.__esModule y sin una propiedad default, Rolldown puede vincular una importación al objeto completo module.exports en lugar de intentar adivinar un valor por defecto como lo hacía la configuración permisiva anterior:
// This used to just work under Vite 7 (esbuild + Rollup)
import DOMPurify from 'dompurify';
DOMPurify.sanitize(input);
// Under Rolldown's stricter CJS interop, this can throw:
// TypeError: e is not a function
// because the import resolved to the whole exports object,
// not the function you expected
Propiedad peligrosa de esta clase: los sistemas de integración suelen pasarla por alto. jsdom o las suites de simulación rara vez ejecutan el verdadero artefacto de producción. Las fallas aparecen cuando un navegador carga el resultado generado. La opción legacy.inconsistentCjsInterop: true de Vite restaura el antiguo comportamiento permisivo mientras se investiga la dependencia problemática.
manualChunks está obsoleto en favor de advancedChunks. El cambio no consiste en una búsqueda y reemplazo simple. Algunos equipos han experimentado el error ReferenceError: Cannot access 'x' before initialization debido a efectos secundarios relacionados con el orden de los chunks tras su reagrupación, y al menos un informe describió 575 chunks con la configuración predeterminada de Rolldown antes de realizar ajustes manuales.
// Old, now-deprecated approach
build: {
rollupOptions: {
output: {
manualChunks: {
vendor: ['react', 'react-dom'],
},
},
},
}
// Rolldown's replacement - more powerful, but a real migration
build: {
rolldownOptions: {
output: {
advancedChunks: {
groups: [
{ name: 'vendor', test: /node_modules/, priority: 100 },
],
},
},
},
}
Caso documentado: @cloudflare/style-provider de Cloudflare (híbrido ESM+CJS) presentó el error createRenderer is not a function porque Rolldown emitió un inicializador anónimo e inaccesible para la parte en CJS. La corrección realizada creó un alias del paquete hacia su entrada en CJS dentro de la configuración de Vite; el uso puro de CJS a través de la interoperabilidad de Rolldown funcionaba bien, pero no el formato híbrido.
Código fuera de la aplicación: El enlace nativo de Rust de Rolldown no pudo cargarse dentro de StackBlitz WebContainers, lo que afectó a muchas plantillas de entorno de pruebas del navegador hasta que los proyectos pasaron a usar Vite 7 mientras el equipo responsable seguía investigando el problema.
Lista de verificación para una migración más segura
Los equipos que completaron la transición se centran en detalles concretos, y no simplemente en “actualizar y esperar”.
Bugues misteriosos del tipo “Vite 7 funcionaba, Vite 8 falla”: pruebe primero experimental: { enableNativePlugin: false }. Ahora los complementos nativos de Rust son la opción predeterminada; desactivarlos soluciona una proporción sorprendente de fallos inexplicables.
Cargue el paquete real para producción en un navegador real antes de realizar la implementación. jsdom no detectará las clases de interoperabilidad CJS a menos que ejecute el archivo compilado.
Trate manualChunks → advancedChunks como un proyecto real con su propio proceso de pruebas. Los errores relacionados con el orden de los chunks parecen normales hasta que se ejecuta una ruta específica.
Reduce los riesgos con rolldown-vite (Vite 7 + vista previa de Rolldown) en tu código antes de pasar a Vite 8.
Si una dependencia crítica aún no está lista para Rolldown, seguir usando Vite 7 para esa compilación es una opción válida; es mejor que inventar soluciones temporales frágiles bajo plazo límite.
Quiénes deberían esperar problemas
Dependencias ESM estándar y particionamiento ligero por defecto: las actualizaciones suelen ser sin problemas, y solo la compatibilidad ya vale la pena. manualChunks personalizados, paquetes híbridos CJS/ESM o hosts inusuales (cajas de arena del navegador, WebContainers): ten en cuenta el tiempo necesario para la migración y prueba el resultado en navegadores. Esos fallos pasan las pruebas CI sin problemas y solo aparecen para usuarios reales con paquetes reales.
Lección más importante
Cuando dos sistemas que antes solapaban sus límites se unen en uno solo, las costuras anteriormente invisibles aparecen de golpe. Eso no significa que la unificación haya sido un error. La paridad entre entornos de desarrollo y producción representa una verdadera mejora estructural, y las cifras de velocidad se mantienen. Significa que “eliminamos las discrepancias” y “aparecerá una ola de errores específicos y localizables durante la transición” son el mismo hecho en días calendario diferentes. El escepticismo hacia Rolldown es la actitud incorrecta; el escepticismo hacia un CI en modo verde sin un paquete de producción cargado en el navegador sí es la actitud adecuada.
Qué incluir en la solicitud de migración
Escriba la actualización como un cambio de ingeniería con criterios de aceptación, no como un aumento de dependencias.
Criterios sugeridos:
- La compilación para producción se complete bajo Rolldown con los mismos recursos públicos que se esperan.
legacy.inconsistentCjsInterop, especificando un responsable y una fecha de vencimiento.manualChunks a advancedChunks con una prueba específica.Si algún criterio falla, permanezca con Vite 7 o con rolldown-vite hasta que se cumpla. Publicar un bundler más rápido que cause problemas en producción no representa una mejora de rendimiento.
Por qué los errores de paridad parecen personales
Los desarrolladores confían en el servidor local. Cuando el servidor local y la versión de producción dejan de entrar en conflicto, los errores que antes se ocultaban en esos conflictos aparecen en un solo lugar. Eso puede dar la sensación de que el sistema “introdujo” fallos que siempre estuvieron latentes debido a la ambigüedad del CJS o a los gráficos de bloques. Nombrar ese patrón reduce el pánico: no se está persiguiendo una regresión aleatoria; se están revelando las grietas que la era de doble motor había ocultado.
Mantenga las cifras relacionadas con la velocidad. Mantenga el diseño de motor único. Simplemente no confunda un conjunto de pruebas con resultados positivos con la certeza de que el artefacto generado funciona correctamente.
Lecturas relacionadas
- Elegir un bundler hoy: Vite, Webpack, Rspack y Turbopack comparados — Entienda cuáles son las verdaderas diferencias entre Vite y Webpack, qué cambios han introducido las versiones recientes, en qué aspectos cada uno sigue teniendo limitaciones, y cómo Rspack y Turbopack influyen en su decisión sobre el bundler.
- JSX no es HTML dentro de JavaScript: es un paso de compilación — El JavaScript puro no puede interpretar la sintaxis con corchetes angulares; JSX es una sintaxis similar al HTML que Babel o Vite reescriben en llamadas a createElement antes de que el navegador la ejecute.