Noticias

**Nuxt 3 llegó al final de su vida útil el 31 de julio de 2026.** El anuncio lo hizo Daniel Roe, mantenedor principal del framework, en la versión Nuxt 4.3.0 publicada el 22 de enero de 2026. Si tienes una aplicación Nuxt 3 en producción, esa fecha ya ha pasado.

Lo primero que conviene dejar claro es lo que el fin de vida **no** significa. Nada se rompe. Tu aplicación no dejó de funcionar el 1 de agosto, ningún paquete fue retirado y `npm install` sigue resolviendo. El fin de vida es un compromiso de soporte que termina, no un interruptor.

Qué significa realmente el fin de vida

Lo que sí significa es que **Nuxt 3 ya no recibe actualizaciones de seguridad ni correcciones de errores críticos**. Cualquier vulnerabilidad divulgada a partir de ahora se corregirá en la línea de la versión 4 y no se retroportará. Eso es todo, y basta: un framework sin parchear en la ruta de las peticiones de una aplicación pública es un pasivo que crece en silencio, según el calendario de otros y no el tuyo.

Hay un detalle en esta historia que merece más atención de la que recibe, porque dice algo sobre la migración misma. **La fecha original de fin de vida era el 31 de enero de 2026.** Los mantenedores abrieron una discusión para saber cómo estaba yendo realmente el paso de la versión 3 a la 4, y lo que escucharon les llevó a ampliar el soporte seis meses, manteniendo las actualizaciones de seguridad y las correcciones críticas más allá de la fecha ya anunciada.

Es un equipo de mantenedores que se comporta bien, y también una señal que conviene leer sin rodeos: la actualización era lo bastante difícil, para bastante gente, como para justificar mover un plazo publicado. Si llevas meses posponiéndola, no estás solo y el proyecto lo sabía.

El plazo que ya se movió una vez

El corolario es menos cómodo. **La prórroga ya se ha usado.** Un plazo que ya se movió una vez, tras una consulta pública, no es un plazo del que quepa esperar un segundo aplazamiento. Contar con ello sería contar con la buena voluntad.

• `nuxt/4/file-structure` - los cambios de estructura de directorios introducidos en la versión 4
• `nuxt/4/default-data-error-value` - el nuevo valor por defecto de data y error
• `nuxt/4/deprecated-dedupe-value` - eliminación de los valores de dedupe obsoletos
• `nuxt/4/shallow-function-reactivity` - reactividad superficial para funciones
• `nuxt/4/absolute-watch-path` - las rutas vigiladas pasan a ser absolutas
• `nuxt/4/template-compilation-changes` - cambios en la compilación de plantillas

Al otro lado de la migración, la versión estable actual es **Nuxt 4.5.1**. La actualización empieza con un solo comando, que la documentación ofrece para cada gestor de paquetes: `npx nuxt upgrade`, o sus equivalentes en `yarn`, `pnpm`, `bun x` y `deno x`.

Ese comando mueve la dependencia. No reescribe tu código, y ahí está la mayor parte del trabajo real. Nuxt publica **codemods oficiales** para esa parte, reunidos en una única receta de migración: `npx codemod@0.18.7 nuxt/4/migration-recipe`. Fíjate en la versión fijada. La documentación la ancla a propósito en lugar de usar `@latest`, para que la transformación que ejecutas sea la que se probó contra esta migración.

La receta agrupa varios codemods individuales, y vale la pena conocerlos por separado, porque una base de código grande suele necesitar aplicarlos uno a uno en vez de todos a la vez. Son estos.

Actualizar: el comando y los codemods

Nada de esto hace la migración automática. Los codemods resuelven cambios mecánicos, reconocibles por un patrón; no razonan sobre tu aplicación, tus módulos ni los paquetes de terceros de tu árbol de dependencias, que tienen sus propios calendarios de compatibilidad. Reserva tiempo para lo que una herramienta no puede ver. Pero la parte mecánica está realmente cubierta, y es justo la que más se suele dar por hecho que habrá que hacer a mano.