El lunes arrancas la semana, abres el proyecto, y ves que hay una nueva versión de Vite disponible. La actualizas casi en automático — llevas años confiando en que las minor no rompen nada.
Esta vez, una advertencia en la consola: está deprecado. Buscas en la documentación. El nombre cambió. Nada grave, pero te detiene cinco minutos.
Eso es exactamente lo que hace Vite 8.1: llega sin hacer ruido, resuelve cosas que probablemente ya te estaban molestando sin que lo supieras, y mete una feature experimental que puede cambiar cómo experimentas el desarrollo en proyectos grandes. Si todavía no la has revisado, este post te ahorra el tiempo de buscarla tú.
se publicó el 23 de junio de 2026 y, según las propias métricas del proyecto, ya hay 41,6 millones de descargas semanales — casi las mismas que acumuló toda la era de Vite 7.
Vite 8.1 es la versión minor del bundler de frontend que introduce bundled dev mode experimental, soporte WASM ESM nativo, chunk import maps y mejoras en LightningCSS — todo sobre la base de Rolldown, el motor Rust que reemplazó a esbuild y Rollup en Vite 8.0.
El dev server de Vite siempre ha funcionado en modo _unbundled_: sirve cada módulo como un fichero independiente aprovechando ESM nativo del navegador. Es lo que lo hace rápido en proyectos medianos. El problema viene cuando el proyecto crece.
En una app con 10.000 componentes React, el navegador tiene que resolver 10.000 requests en cadena. El HMR se mantiene instantáneo, pero la carga inicial y los reloads completos se vuelven lentos.
junta los módulos antes de servirlos — igual que haría un build de producción, pero con la ventaja de que el HMR sigue siendo incremental y preciso. Los números que publica el equipo de Vite:
- ~15x de arranque más rápido para apps grandes
- ~10x de reloads completos más rápidos
- 10x menos requests de red
El equipo de Linear (la herramienta de gestión de proyectos) lo probó en producción: cold start 3x más rápido, reloads 40% más rápidos.
Para activarlo, tienes dos opciones:
# Desde la CLI
vite --experimental-bundle// vite.config.ts
export default defineConfig({
experimental: {
bundledDev: true,
},
})Es experimental. No lo actives en CI ni en producción todavía — el equipo todavía lo está refinando. Pero en desarrollo local, sobre todo si tu proyecto tiene cientos de rutas o módulos, pruébalo esta semana.
Hasta ahora, importar un módulo WebAssembly en Vite requería configuración extra o un plugin. En Vite 8.1 ya es nativo con la integración de :
import { add } from './add.wasm'
console.log(add(1, 2)) // 3
Sin configuración adicional. Sin plugins. El módulo expone sus funciones directamente como named exports de ES Module.
Esto es relevante si estás construyendo herramientas de procesamiento de datos, encoders, parsers, o cualquier lógica computacionalmente intensiva que tenga sentido compilar desde Rust o C. El flujo de trabajo Rust → → Vite ya no tiene fricción.
El problema de los hashes en cascada es conocido: cambias una línea en un componente, el hash de ese chunk cambia, y ese cambio se propaga al chunk que lo importa, que cambia su hash también, y así en cadena. El resultado: el navegador invalida más caché de la necesaria.
Vite 8.1 introduce soporte para como feature experimental. En lugar de que los hashes de los módulos dependientes cambien cuando cambia un imported chunk, el import map actúa como capa de indirección. El chunk padre sigue apuntando al mismo nombre lógico; el import map resuelve el nombre al hash real.
// vite.config.ts
export default defineConfig({
experimental: {
bundledDev: true,
// chunkImportMap se activa automáticamente con bundledDev
},
})No requiere configuración adicional en . Limitación actual: no es compatible con . Si lo usas, espera a que lo resuelvan antes de activarlo.
Vite lleva varios releases preparando el terreno para que LightningCSS sustituya a PostCSS como procesador CSS por defecto. En 8.1 llegan dos adiciones concretas:
- dentro de archivos CSS cuando usas LightningCSS
- mediante plugins — necesario para que el HMR funcione correctamente cuando un plugin modifica ficheros que no están directamente en el grafo de dependencias
Para activar LightningCSS:
// vite.config.ts
export default defineConfig({
css: {
transformer: 'lightningcss',
},
})Si ya estás en , estas dos adiciones te llegan sin hacer nada. Si sigues con PostCSS, no hay prisa — pero la dirección del proyecto es clara.
tiene un bug silencioso en el que la opción funcionaba en la resolución inicial de módulos pero no en el matching del HMR. Cambiabas un fichero, y Vite no lo detectaba si el nombre diferenciaba mayúsculas/minúsculas de forma inesperada.
En 8.1 ya está corregido:
const modules = import.meta.glob('./dir/module*.js', {
caseSensitive: false,
})Ahora tanto la resolución inicial como el HMR respetan la misma sensibilidad a mayúsculas. Si tenías workarounds para esto, puedes eliminarlos.
Vite detecta assets en el HTML buscando atributos conocidos: , , , etc. Si tienes elementos o atributos custom que referencian assets, Vite los ignoraba.
Ahora puedes configurarlo explícitamente:
// vite.config.ts
export default defineConfig({
html: {
additionalAssetSources: [
{ tag: 'my-image', attribute: 'data-src' },
{ tag: 'x-video', attribute: 'poster-url' },
],
},
})Útil si trabajas con Web Components o frameworks que usan atributos no estándar para referenciar recursos.
Vite ahora amplía la lista de ficheros denegados por defecto en . Ficheros comunes que no deberían exponerse en el dev server quedan bloqueados sin que tengas que configurarlo manualmente.
Si tienes una configuración explícita de , revísala — puede haber solapamientos. Si confías en el comportamiento por defecto, simplemente tienes una superficie de ataque más pequeña sin hacer nada.
Este es el cambio que genera la advertencia de deprecación que mencioné al principio.
La opción tenía un nombre ambiguo — HMR es el protocolo, pero la configuración afectaba al WebSocket server completo, que también se usa para comunicaciones que no son HMR. El nuevo nombre refleja mejor qué estás configurando.
// Antes (deprecado en 8.1)
export default defineConfig({
server: {
hmr: {
port: 24678,
host: 'localhost',
},
},
})
// Ahora export default defineConfig({ server: { ws: { port: 24678, host: 'localhost', }, }, })
La opción antigua sigue funcionando — verás el warning pero no se rompe nada. Migra cuando puedas, no es urgente.
Vite 8.1 integra soporte para con caché de build zero-config. Si ya estás usando Vite Task (la nueva API de tareas del ecosistema), los builds se cachean automáticamente sin configuración adicional.
Es una adición menor para la mayoría de proyectos, pero importante si tienes monorepos donde los builds repetidos son costosos.
La migración desde 8.0 es prácticamente sin fricción. Los pasos concretos:
# npm
npm install vite@^8.1 --save-dev
# pnpm pnpm update vite@^8.1
# yarn yarn upgrade vite@^8.1
# bun bun update vite
Después de actualizar, revisa estos tres puntos:
si tienes configuración explícita del WebSocket server. La advertencia en consola te lo indica exactamente.
si tienes reglas custom. Los nuevos defaults pueden solapar con las tuyas y crear comportamientos inesperados.
si usas la opción directamente. Migra al sistema estándar de ficheros .
Si vienes de Vite 7.x, revisa primero la — hay cambios más sustanciales en el salto de major, como el motor Rolldown que reemplaza a esbuild+Rollup. Precisamente, si te interesa cómo Astro v7 aprovecha Vite 8 en producción, tienes el análisis completo en .
Si estás en Vite 7 y quieres pasar directamente a 8.1, el cambio más importante es . Vite 8.0 reemplazó esbuild (para transform) y Rollup (para bundle) por Rolldown, un bundler escrito en Rust. El resultado es hasta 30x más rápido en builds grandes, pero hay diferencias de comportamiento en edge cases.
La documentación oficial tiene la guía completa. Lo que suele dar problemas en la práctica:
- Plugins que asumen comportamientos específicos de Rollup en hooks de resolución
- Configuraciones de
— pasan automáticamente apero no todo es compatible 1:1 - Targets de CSS con PostCSS si usas configuraciones muy custom
Mi recomendación: si tienes un proyecto en producción con Vite 7, dedica una tarde a la migración en una rama separada antes de mergearla. Si además estás evaluando qué herramientas usar en un stack moderno con IA, el post sobre el te da el mapa completo de qué merece la pena y qué ignorar. No es un upgrade de dos minutos, pero tampoco es traumático si el proyecto no tiene plugins exóticos.
Sí. Vite 8.1 es agnóstico al framework. Los plugins oficiales (@vitejs/plugin-react, @vitejs/plugin-vue, @analogjs/vite-plugin-angular, @sveltejs/vite-plugin-svelte) ya tienen versiones compatibles con Vite 8.x. Verifica en el de cada plugin que el peerDependency incluye .
Cuando notes que tu dev server tarda más de 3-5 segundos en arrancar o que los reloads completos son lentos. En proyectos pequeños y medianos (menos de 500 módulos), el modo unbundled sigue siendo más rápido. El beneficio de bundled dev mode es proporcional al tamaño del proyecto.
Casi. LightningCSS cubre la mayoría de casos: prefixing, nesting nativo, variables CSS, imports. Lo que todavía puede requerir PostCSS son plugins muy específicos del ecosistema (px a rem, ciertas transformaciones custom). Si tu stack CSS es estándar, prueba a migrar — las mejoras de velocidad son notables.
No. Esta opción solo afecta al servidor de desarrollo. En producción, Vite no levanta un WebSocket server — esa configuración es irrelevante. El cambio es puramente de nomenclatura en el dev server.
Vite 8 requiere Node.js 18+ (igual que Vite 7). Si estás en Node 16 o inferior, tendrás que actualizarlo antes de poder usar Vite 8.x.
Rolldown es el motor por defecto desde Vite 8.0 y se considera estable para uso en producción. Los flags experimentales son para features específicas (bundled dev mode, chunk import map) — no para Rolldown en sí. Para la mayoría de proyectos, Rolldown funciona como un drop-in replacement de Rollup.
Vite 8.1 no es una release que te obligue a cambiar cómo trabajas. La mayor parte de las features son opt-in o correcciones de bugs que funcionan transparentemente.
Lo que sí cambia si lo adoptas activamente:
El puede hacer que trabajes diferente en proyectos grandes — menos tiempo esperando recargas, más tiempo en el problema real. El abre la puerta a traer lógica Rust o C al frontend sin fricción. Y el empieza a resolver uno de los problemas crónicos del caching en producción.
Si trabajas con agentes de IA para acelerar tu desarrollo — donde cada segundo de feedback loop importa — el bundled dev mode encaja directamente en ese flujo. Es parte del tipo de optimizaciones que exploramos en el : no solo usar IA para generar código, sino construir un entorno donde iterar sea rápido de verdad.
Y si quieres ver cómo aplico estas decisiones de toolchain en proyectos reales con código completo, pásate por — ahí está el material avanzado que no llega al blog.
Leave a Reply