La arquitectura de dos mitades: dev y build

Vite tiene una doble naturaleza que hay que ver con claridad para no confundirse nunca. No es un servidor con un exportador pegado al final: son dos máquinas distintas, gobernadas por un mismo vite.config.ts, que optimizan objetivos contrarios. La mitad de desarrollo persigue iterar en milisegundos y por eso no empaqueta. La mitad de producción persigue cargar rápido en la red de un usuario real y por eso empaqueta con esmero. Entender por qué difieren —y dónde esa diferencia ha causado dolor histórico— es entender la ingeniería de Vite.

Dos naturalezas, un solo config

Cuando ejecutas vite, arrancas la mitad de desarrollo: un servidor que sirve tu código fuente como ESM nativo, sin empaquetar, con HMR quirúrgico.

Cuando ejecutas vite build, invocas la otra mitad: un compilador que recorre el grafo desde index.html y produce un bundle optimizado en dist/.

Comparten configuración, plugins y resolución de módulos, pero son procesos con motores y prioridades diferentes. La razón de que existan dos es que ningún compromiso sirve para ambos mundos.

Si empaquetaras en desarrollo, perderías el arranque instantáneo y el HMR fino. Si sirvieras ESM sin empaquetar en producción, condenarías al usuario a una experiencia lenta. Cada mitad, por tanto, toma la decisión opuesta a conciencia.

Que ambas compartan vite.config.ts es lo que garantiza que resuelvan los módulos igual y apliquen los mismos plugins. El archivo tiene secciones dedicadas a cada mitad:

import { defineConfig } from "vite";

export default defineConfig({
  server: {
    port: 5173,          // opciones de la mitad de desarrollo
  },
  build: {
    outDir: "dist",      // opciones de la mitad de produccion
    sourcemap: true,     // mapas para depurar el bundle minificado
  },
});

La clave server solo afecta al dev server; la clave build, solo al empaquetado. Los plugins y los resolve.alias, en cambio, se aplican a las dos mitades, y esa parte compartida es la que asegura coherencia entre lo que ves al iterar y lo que despliegas.

Por qué el ESM sin bundle no vale para producción

En tu máquina, servir doscientos módulos sueltos por localhost es gratis: la latencia es nula y todo está en caché. En la red real de un usuario, cada módulo es un viaje de ida y vuelta.

Los import anidados crean una cascada: el navegador no puede pedir un módulo hasta que ha recibido y leído el que lo importa. Doscientas peticiones encadenadas son un desastre de rendimiento, sobre todo en redes móviles con latencia alta.

Por eso la mitad de producción no se limita a servir: transforma el grafo con una batería de optimizaciones que solo tienen sentido al entregar.

• Tree shaking: elimina el código que nadie usa, imposible sin ver el grafo entero.
• Code splitting: parte el bundle en trozos que se cargan bajo demanda.
• Minificación: reduce los bytes acortando nombres y quitando espacios.
• Hashing: pone un sello de contenido en cada nombre para cachear con seguridad.

El ESM sin bundle es la herramienta correcta para iterar y la incorrecta para entregar. Ese es, en una frase, el porqué de las dos mitades.

flowchart TB
cfg[vite.config.ts] --> d1[ESM sin bundle]
cfg --> b1[lee index.html]
subgraph Desarrollo
  d1 --> d2[transforma por peticion]
  d2 --> d3[HMR quirurgico]
end
subgraph Produccion
  b1 --> b2[recorre el grafo]
  b2 --> b3[tree shaking]
  b3 --> b4[minifica y hashea]
  b4 --> b5[dist]
end
style cfg fill:#f9e2af,color:#11111b
style d1 fill:#89b4fa,color:#11111b
style b1 fill:#a6e3a1,color:#11111b

La mitad de desarrollo por dentro

El pipeline de desarrollo es reactivo. Ante cada petición, Vite resuelve el especificador a un archivo, lo transforma —tipos fuera, JSX a funciones, import reescritos— y lo sirve.

Solo hay una pieza que empaqueta: el pre-bundling de dependencias, que agrupa lo que sacas de node_modules para evitar la cascada de peticiones. Ese pre-bundling lo ha hecho históricamente esbuild.

Todo lo demás —tu código fuente— viaja sin empaquetar, módulo a módulo, para que el HMR pueda tocar un solo nodo del grafo cuando guardas.

El ciclo que Vite repite ante cada petición es siempre el mismo:

• Resuelve el especificador del import a un archivo real en disco.
• Transforma ese archivo con el motor nativo, sin tocar los demás.
• Reescribe sus import internos a rutas que el navegador sabe pedir.
• Lo entrega con cabeceras de caché y vuelve a quedarse a la espera.

Ese bucle, repetido a la velocidad de un motor nativo, es lo que hace que arrancar y trabajar se sientan sin latencia:

VITE v8.0.0  ready in 128 ms
Local:   http://localhost:5173/

La mitad de producción y la costura entre motores

El pipeline de build es exhaustivo. Toma index.html como raíz, sigue cada import, construye el grafo completo, aplica las optimizaciones y escribe dist/. Ese empaquetado lo ha hecho históricamente Rollup.

El resultado no son módulos sueltos, sino pocos archivos con nombres versionados por contenido:

dist/
  index.html
  assets/
    index-a1b2c3.js      # tu codigo, empaquetado y minificado
    vendor-d4e5f6.js     # las dependencias, en su propio chunk
    index-9f8e7d.css     # el CSS extraido y hasheado

Y aquí aparece la costura que hay que conocer. Durante años, la mitad de desarrollo usó esbuild (Go) para las dependencias y la mitad de producción usó Rollup (JavaScript). Dos motores, dos lenguajes, dos formas sutilmente distintas de resolver, transformar y ordenar módulos.

La consecuencia práctica era el problema de paridad dev/prod: código que funcionaba perfecto en el servidor podía comportarse distinto tras el build. Y depurar esas diferencias era doloroso precisamente porque nacían de que ambas mitades hablaban idiomas distintos.

vite          # mitad dev: esbuild pre-empaqueta deps, ESM para tu codigo
vite build    # mitad prod: Rollup empaqueta todo el grafo
vite preview  # sirve dist/ para ver el resultado real de produccion