Vite 8 en 2026: Rolldown y el motor único

Durante toda su primera década, Vite fue rápido a pesar de estar hecho de piezas dispares: esbuild en Go para el desarrollo, Rollup en JavaScript para la producción. Vite 8, la versión que define 2026, culmina un cambio de fondo: un único motor, Rolldown, escrito en Rust sobre el toolchain Oxc, se ocupa de ambas mitades. No es una optimización más; es la unificación que cierra la costura histórica de Vite y marca el fin de la era del tooling de JavaScript fragmentado. Esta lección explica qué es Rolldown y, sobre todo, qué implica para tu proyecto.

De dos motores a uno

Recordemos la costura de la lección anterior. La mitad de desarrollo pre-empaquetaba dependencias con esbuild; la mitad de producción empaquetaba todo el grafo con Rollup.

Eran dos programas distintos, en dos lenguajes, con dos formas sutilmente diferentes de resolver, transformar y ordenar módulos. Esa dualidad era la raíz del problema de paridad: un mismo proyecto podía comportarse distinto en dev y en build porque, literalmente, lo procesaban cerebros diferentes.

La evolución del motor cuenta la historia en tres actos:

# El motor de Vite a lo largo del tiempo
Vite 2 a 6   ->  esbuild (dev) + Rollup (build)
Vite 7       ->  rolldown-vite como opcion, un puente para probar
Vite 8       ->  Rolldown por defecto en las dos mitades

Cada motor tenía además su límite propio. esbuild era rapidísimo pero poco flexible como bundler de producción, con un modelo de plugins más pobre.

Rollup producía un output excelente y tenía un ecosistema de plugins enorme, pero, al estar en JavaScript, se convertía en el cuello de botella de los builds grandes.

Vite quedó atrapado entre la velocidad de uno y la calidad del otro, sin poder tener ambas en un solo motor.

La salida a ese dilema no era optimizar ninguno de los dos por separado, sino escribir un bundler nuevo desde cero, pensado para no tener que elegir entre rapidez y capacidad.

Rolldown: un bundler en Rust sobre Oxc

Rolldown es ese bundler. Lo desarrolla el propio equipo de Vite —bajo VoidZero, la empresa fundada por el creador de Vite— y está escrito en Rust para alcanzar velocidad nativa.

Se apoya en Oxc, que reúne en una sola base en Rust las piezas que antes venían de proyectos distintos:

• Un parser que convierte tu código en un árbol de sintaxis.
• Un resolver que localiza cada módulo importado.
• Un transformer que borra tipos y rebaja sintaxis.
• Un minifier que comprime el output final.

La decisión de diseño clave es que Rolldown expone una API de plugins compatible con Rollup. El enorme ecosistema de plugins que Vite heredó de Rollup sigue funcionando, y la migración no obliga a reescribir la configuración.

Rolldown aspira a ser, a la vez, tan veloz como esbuild y tan capaz como Rollup: la pieza que resuelve el dilema en el que Vite estaba atrapado.

flowchart TB
subgraph Antes
  a1[dev con esbuild en Go]
  a2[build con Rollup en JS]
end
subgraph Vite8
  r1[Rolldown en Rust] --> r2[sobre Oxc]
end
a1 --> r1
a2 --> r1
style a1 fill:#f38ba8,color:#11111b
style a2 fill:#f38ba8,color:#11111b
style r1 fill:#a6e3a1,color:#11111b

Qué cambia para tu proyecto

La buena noticia para el día a día es que casi todo el cambio ocurre bajo el capó. En un proyecto Astro, por ejemplo, Vite es una dependencia interna: actualizas y heredas Rolldown sin tocar tu código. Aun así, conviene saber qué esperar.

• Builds mucho más rápidos. En proyectos grandes, el empaquetado de producción pasa de ser el paso lento del pipeline a costar una fracción, porque el motor es nativo. La mejora se nota sobre todo en monorepos y aplicaciones con miles de módulos.
• Paridad dev/prod. Al pre-empaquetar dependencias y construir producción con el mismo motor, desaparece la clase de bug que solo aparecía tras el build.
• Migración casi transparente. Gracias a la compatibilidad con la API de Rollup, la mayoría de plugins y configuraciones siguen igual. Algunos plugins muy dependientes de internos de Rollup pueden necesitar una actualización.
• Modo de bundle opcional en dev. Para aplicaciones enormes, Rolldown permite experimentar con empaquetar también en desarrollo, reduciendo el número de peticiones cuando el ESM sin bundle empieza a ser demasiadas.

La compatibilidad se nota hasta en los nombres: la clave para afinar el empaquetado sigue llamándose rollupOptions, aunque por debajo ya la atienda Rolldown.

// vite.config.ts: los ajustes finos del bundle no cambian de nombre
export default defineConfig({
  build: {
    rollupOptions: {
      output: { manualChunks: { vendor: ["react", "react-dom"] } },
    },
  },
});

En la era de Vite 7, Rolldown se probaba con un paquete puente. En Vite 8 es el motor por defecto y no hace falta nada extra:

pnpm why vite         # confirma la version de Vite en el arbol
pnpm list rolldown    # comprueba si Rolldown ya esta por debajo

En la práctica, adoptar Vite 8 se parece a cualquier otra subida de versión mayor, y se reduce a tres pasos:

• Sube la versión y deja que Rolldown entre como motor por defecto.
• Ejecuta vite build y revisa que ningún plugin proteste.
• Verifica el resultado con vite preview antes de desplegar.

pnpm up vite@8               # actualiza al motor unificado
pnpm build && pnpm preview   # comprueba el bundle real antes de subir

El horizonte: un toolchain unificado

Rolldown no es una pieza suelta, sino el eje de una apuesta mayor. La visión de VoidZero es reunir todo el tooling de JavaScript en una única base en Rust: el bundler (Rolldown), las utilidades de lenguaje (Oxc), el servidor de desarrollo (Vite) y el test runner (Vitest).

Esa base sería coherente y sin costuras entre herramientas escritas por equipos distintos. Es el intento más serio de acabar con la fragmentación que definió el frontend de la década anterior, cuando cada herramienta traía su propio parser y sus propias grietas en las junturas.

Para ti, la consecuencia es doble, y conviene tenerla clara.

A corto plazo, ganas builds más veloces y menos sorpresas al desplegar. A largo plazo, heredas un ecosistema que por fin entiende tu código de una sola manera, de principio a fin: el mismo análisis en el editor, en el servidor, en el bundle y en las pruebas.