Vite 7 elimina CJS y apuesta todo por ESM nativo: guía de migración sin drama
El empaquetador más popular del ecosistema corta por lo sano con CommonJS. Qué rompe, qué mejora y cómo adaptar tu proyecto en menos de un día.
Había una fecha marcada en el calendario de la comunidad JavaScript desde hace meses: el lanzamiento de Vite 7 y su decisión de eliminar el soporte para CommonJS (CJS) como formato de salida. Esa fecha llegó esta semana y, aunque la transición es más suave de lo que algunos temían, merece la pena entender bien qué significa y cómo prepararse.

La decisión no es caprichosa. ESM nativo lleva siendo el estándar oficial de JavaScript desde 2015 y el ecosistema lleva años en una transición lenta pero inexorable hacia él. Node.js tiene soporte completo desde la versión 12. Todos los navegadores modernos lo soportan sin polyfills. Deno y Bun nacieron directamente sobre ESM. Seguir manteniendo CJS en Vite implicaba un overhead de complejidad creciente para un beneficio que se reducía cada mes.
¿Qué cambia exactamente?
Lo que desaparece en Vite 7 es la opción de generar bundles en formato CJS cuando construyes librerías o aplicaciones con vite build. El dev server, que siempre ha trabajado con ESM nativo en el navegador, no cambia en nada.
Si construyes una aplicación web normal (SPA, SSR con Nuxt o SvelteKit), probablemente no notes ninguna diferencia. Los frameworks ya gestionan esta capa internamente y sus plugins para Vite ya están actualizados.
Donde sí hay trabajo es si:
- Publicas una librería de npm que genera salida CJS para compatibilidad con Node.js antiguo.
- Tienes scripts de Node.js que importan código de tu aplicación directamente.
- Usas
require()en algún fichero de configuración de Vite.
La migración en tres pasos
Paso 1: Asegúrate de que tu package.json tiene "type": "module".
Paso 2: Si tienes partes del monorepo que no pueden ser ESM todavía, renombra vite.config.js a vite.config.mjs para que Vite lo trate como ESM sin afectar al resto.
Paso 3: Actualiza las entradas de tu librería en package.json para usar el campo "exports" en lugar de "main".
{
"exports": {
".": {
"import": "./dist/index.js",
"types": "./dist/index.d.ts"
}
}
}
Lo que ganas a cambio
El beneficio más inmediato es velocidad de build. Al no tener que transformar ESM a CJS, Vite hace menos trabajo. En proyectos grandes, equipos que han migrado en preview reportan reducciones del 15-20% en tiempo de build de producción.
También mejora la experiencia de HMR en desarrollo. Algunos patrones de importación dinámica que antes tenían comportamientos inconsistentes entre dev y producción ahora se comportan igual en ambos entornos, lo que elimina una categoría entera de bugs difíciles de reproducir.
El ecosistema está listo: la gran mayoría de plugins de Vite populares ya tienen versiones compatibles. El equipo de Vite publicó una compatibility matrix semanas antes del lanzamiento para que los mantenedores de plugins pudieran prepararse. Si tienes dudas sobre alguna dependencia específica, ese documento es el primer lugar donde mirar.
TAGS
Sara Köhler
Análisis de Producto
// Relacionados

Baseline 2026: las 12 APIs web que ya puedes usar sin polyfills en todos los navegadores

React Server Components: la cola larga de la migración
