Migración: el puente rolldown-vite y el salto a Vite 8

Reemplazar el motor de una herramienta que usan millones de proyectos es una operación delicada: si obligas a todos a migrar de golpe, rompes el ecosistema; si esperas a la perfección, nunca lo lanzas. Vite resolvió el dilema con una migración en dos tiempos. Primero, un paquete puente —rolldown-vite— que dejaba a cualquiera cambiar el motor a Rolldown sobre Vite 7 sin tocar la configuración, probarlo en producción y reportar fricciones. Después, cuando la compatibilidad estaba demostrada, Vite 8 hizo de Rolldown el valor por defecto. Este nivel es la guía práctica de ese camino y la explicación de por qué apenas se notó.

El puente: rolldown-vite

El paquete rolldown-vite fue la pieza clave de la fase de transición. Es un reemplazo directo del paquete vite que sustituye el motor por Rolldown sin cambiar la API pública: la misma configuración, los mismos plugins, los mismos comandos. La forma habitual de adoptarlo era redirigir el paquete vite hacia él mediante un alias en el gestor de paquetes, de modo que todo el proyecto —y las herramientas que dependen de Vite por debajo— usara el motor nuevo sin enterarse.

{
  "dependencies": {
    "vite": "npm:rolldown-vite@latest"
  }
}

Lo que el puente conserva sin que muevas un dedo es justamente lo que hace la adopción trivial:

• Tu vite.config.ts: la misma configuración, sin cambios.
• Tus plugins: los de Rollup y los de Vite siguen cargándose igual.
• Tus comandos: vite, vite build y vite preview no cambian.
• Tus imports: tu código sigue importando de vite, no de rolldown-vite.

La intención de este puente no era solo dar velocidad temprana, sino recabar señal. Al ponerlo en manos de proyectos reales antes de convertirlo en el valor por defecto, el equipo de Vite podía descubrir qué plugins fallaban, qué opciones divergían y qué casos límite faltaban, y arreglarlos con el ecosistema como banco de pruebas. Que la inmensa mayoría de los proyectos funcionara solo con cambiar el alias fue la prueba viviente de que la compatibilidad con la API de Rollup aguantaba el peso real. Y que fuera reversible —basta quitar el alias para volver a Vite 7 clásico— convirtió la prueba en algo de riesgo casi nulo: adoptabas el motor nuevo sabiendo que la puerta de vuelta quedaba abierta.

Qué revisar al migrar

En la mayoría de los casos, migrar es cambiar el alias y volver a ejecutar el build. Pero conviene revisar tres frentes donde pueden aparecer diferencias. El primero son los plugins: casi todos funcionan sin cambios, pero un plugin muy acoplado a detalles internos de Rollup puede necesitar una actualización, y algunos empiezan a aprovechar los filtros de hooks nativos de Rolldown para ir más rápido. El segundo es optimizeDeps: en Vite clásico, el pre-empaquetado de dependencias lo hacía esbuild; con Rolldown lo hace el propio motor, así que el comportamiento del pre-bundling puede variar en detalles sutiles de interoperabilidad entre CommonJS y ESM.

Las señales de que un plugin concreto pide atención son reconocibles, y conviene saber leerlas para no depurar a ciegas:

• Un aviso explícito en la salida del build mencionando un hook o una opción no soportada.
• Un plugin que dependía de un detalle interno de Rollup y no de su API pública.
• Un comportamiento distinto en el pre-empaquetado de una dependencia CommonJS antigua.
• Una opción de configuración que Rolldown expone con otro nombre o que todavía no implementa.

# El flujo de comprobacion tras cambiar el alias
npm install
npm run build      # observa avisos de plugins incompatibles
npm run dev        # verifica el pre-empaquetado de dependencias

El tercer frente son las opciones: hay ajustes de Rollup que Rolldown todavía no replica al cien por cien o que expone con otro nombre, y algún flag experimental puede comportarse distinto. Cuando el pre-empaquetado con Rolldown trate distinto una dependencia CommonJS problemática, acotarla con optimizeDeps suele bastar para encauzarla:

// vite.config.ts: fuerza a incluir una dependencia CommonJS
// en el pre-empaquetado si su interoperabilidad cambia
export default defineConfig({
  optimizeDeps: {
    include: ['una-lib-cjs'],
  },
})

La estrategia recomendada es adoptar rolldown-vite primero para desactivar el riesgo —descubrir estas fricciones sobre Vite 7, donde puedes volver atrás quitando el alias— y solo después dar el salto de versión mayor. Migrar en dos pasos separa el cambio de motor del cambio de versión, y así, si algo falla, sabes cuál de los dos fue.

La estrategia recomendada, paso a paso

Conviene convertir todo lo anterior en un procedimiento repetible en vez de un salto a ciegas. La secuencia que minimiza el riesgo separa cada cambio para que, si algo falla, sepas exactamente qué lo provocó y puedas deshacerlo sin arrastrar lo demás.

• Fija una línea base: cronometra tu build actual y guarda la cifra antes de tocar nada.
• Introduce el alias: apunta vite a rolldown-vite y reinstala; ese es el único cambio de este paso.
• Ejecuta y observa: corre dev y build, revisa avisos de plugins y compara la salida con la línea base.
• Estabiliza: actualiza los plugins que lo pidan y confirma que el artefacto de producción es equivalente.
• Salta de versión: solo cuando el motor esté validado, actualiza a Vite 8 y retira el alias, que ya sobra.

La disciplina de fondo es no mover nunca dos variables a la vez. Si cambiaras el motor y la versión mayor en el mismo paso y algo se rompiera, no sabrías si la culpa fue de Rolldown o de un cambio de Vite 8, y depurarías a ciegas. Adoptar el motor sobre la versión estable y saltar de versión con el motor ya probado te da, en todo momento, una causa aislable y una vía de retirada.

El salto a Vite 8

Vite 8 llegó en marzo de 2026 y cerró la transición: Rolldown pasa a ser el bundler por defecto, sin puente ni alias. El paquete vite ya es el motor en Rust; esbuild y Rollup dejan de ser el corazón del núcleo. Para el usuario, esto significa que un proyecto nuevo con Vite 8 usa un solo motor en dev y en build desde el primer comando, y que el paquete rolldown-vite deja de tener sentido porque su trabajo —probar el motor antes de que fuera el estándar— ya está hecho.

La cronología es coherente con la de todo el ecosistema en 2026: Vite 8 adopta Rolldown por defecto en marzo, y dos meses después, en mayo, Rolldown alcanza su 1.0 estable y congela su API. Dentro de Vite eso importa poco, porque el motor está envuelto por la API de Vite y tú no tocas a Rolldown directamente; pero explica por qué un proyecto pudo hacer de Rolldown su valor por defecto antes de que este publicara su propia versión estable.

flowchart LR
v7[Vite 7 con esbuild y Rollup] --> puente[rolldown-vite como alias]
puente --> prueba[Se prueba en proyectos reales]
prueba --> v8[Vite 8 con Rolldown por defecto]
style puente fill:#f9e2af,color:#11111b
style v8 fill:#94e2d5,color:#11111b
style prueba fill:#a6e3a1,color:#11111b

Lo notable del salto es lo poco que cambia en tu código al darlo. El balance se resume en qué se mueve y qué permanece:

• Cambia por debajo: un motor en lugar de dos, un parser en lugar de dos, una semántica en lugar de dos.
• Permanece intacto: tu config, tus plugins, tus comandos y tu modelo mental del build.
• Desaparece: el paquete rolldown-vite, cuyo trabajo de puente ya está hecho.
• Mejora: el build hereda la velocidad de Rust y la coherencia de un motor único en dev y en producción.

La guía práctica para adoptar Vite 8 es, por eso, casi anticlimática: si ya probaste rolldown-vite, la actualización es un cambio de versión más; si no, actualiza y ejecuta los mismos tres controles de plugins, optimizeDeps y opciones. Ese anticlímax no es un accidente, sino el resultado buscado: una transición bien diseñada se siente como no-evento precisamente porque el trabajo difícil se hizo antes, en la fase del puente.

Visto con distancia, el salto a Vite 8 no es tanto un evento como la ratificación de algo que ya había ocurrido: para cuando Rolldown se volvió el valor por defecto, miles de proyectos llevaban meses ejecutándolo a través del puente. La versión mayor no introdujo el motor nuevo, solo dejó de pedir que lo activaras a mano.