Qué hace una build tool por dentro

Bajo la palabra “build” se esconde siempre la misma tubería, sin importar la herramienta. Una build tool no hace magia: compone cinco tareas bien delimitadas —transpilar, resolver, empaquetar, optimizar y servir— sobre un grafo de módulos. Cuando conoces esas cinco piezas dejas de ver una caja negra y empiezas a leer cualquier bundler, y cualquier error, como lo que es: un paso concreto de un proceso ordenado.

Antes de entrar en detalle, este es el mapa de las cinco tareas. Todo lo que hace una build tool cae en una de ellas.

Transpilar y resolver

La primera tarea es transpilar: transformar cada archivo, uno a uno, en JavaScript que el motor entienda. Aquí se borra TypeScript, se convierte JSX en llamadas a funciones, se rebaja la sintaxis al target elegido y se inyectan los ayudantes que haga falta.

Es una operación local: no necesita saber nada del resto del proyecto, solo del archivo que tiene delante. Los motores que la ejecutan hoy —esbuild, SWC, Oxc— son justamente los que ganaron la carrera de la velocidad.

La segunda tarea es resolver el grafo. Partiendo de uno o varios puntos de entrada, la herramienta lee cada import, encuentra el archivo al que apunta y repite el proceso hasta dibujar el grafo completo de dependencias. Suena trivial y no lo es: la resolución de módulos es uno de los rincones más profundos del ecosistema.

Ese campo exports es hoy el corazón de la resolución moderna. Un mismo paquete puede entregar un archivo distinto según quién lo importe —ESM o CommonJS, navegador o servidor— gracias a las conditions:

{
  "name": "mi-libreria",
  "exports": {
    ".": {
      "import": "./dist/index.mjs",
      "require": "./dist/index.cjs",
      "browser": "./dist/index.browser.mjs"
    }
  }
}

Empaquetar y optimizar

Con el grafo en la mano, empaquetar consiste en fundir esos cientos de módulos en unos pocos archivos, o chunks. Históricamente el motivo era la red: cada archivo era una petición, y muchas peticiones pequeñas penalizaban la carga.

El bundler concatena, reescribe las referencias entre módulos y produce artefactos que el navegador descarga de un tirón. Pero empaquetar sin más produciría archivos enormes. Por eso la cuarta tarea, optimizar, es donde se gana el rendimiento real, y conviene no confundir sus técnicas:

• Tree shaking: análisis estático del grafo ESM para eliminar los export que nadie usa. Es eliminación de código muerto, y solo funciona bien porque ESM es estático y analizable.
• Code splitting: dividir la salida en trozos que se cargan bajo demanda. Un import() dinámico o una ruta perezosa se convierten en un chunk aparte que el navegador solo pide cuando hace falta.
• Minificación: renombrar variables, borrar espacios y comentarios y colapsar código para reducir bytes sin cambiar el comportamiento.
• Hashing de contenido: incrustar un hash en el nombre del archivo —app.9f3a1c.js— para que el navegador cachee de forma agresiva e invalide solo cuando el contenido cambia.

El code splitting nace de una sola pista que tú das en el código: el import() dinámico. Donde lo escribes, el bundler parte el grafo.

// Esta linea le dice al bundler donde partir el grafo en un chunk aparte
const editor = await import("./editor-pesado.js");
// El codigo del editor no viaja en el bundle inicial: se pide al usarse

Tree shaking y code splitting tiran en la misma dirección —enviar lo mínimo— pero por caminos opuestos: uno quita lo que nunca se usa, el otro aplaza lo que no se usa todavía. Juntos convierten un grafo monolítico en una entrega quirúrgica.

A esto se suma el manejo de assets: imágenes, CSS y fuentes también entran al grafo, se les pone hash, y los más pequeños se incrustan en línea para ahorrar peticiones. El resultado es un puñado de archivos con nombres versionados, listos para un CDN.

Servir en desarrollo

La quinta tarea vive en otro tiempo y con otras prioridades. En producción quieres el artefacto más pequeño y rápido, y no te importa esperar unos segundos a que se genere. En desarrollo quieres exactamente lo contrario: arranque instantáneo y ver el cambio en cuanto guardas, aunque el resultado no esté optimizado.

Por eso el dev server moderno no empaqueta: sirve ESM nativo y transforma cada módulo solo cuando el navegador lo pide. La misma tubería, pero recorrida bajo demanda en lugar de entera y por adelantado.

flowchart LR
A[Puntos de entrada] --> B[Resolver grafo]
B --> C[Transpilar cada modulo]
C --> D{Modo}
D -->|produccion| E[Empaquetar]
E --> F[Optimizar]
F --> G[Artefactos con hash]
D -->|desarrollo| H[Servir ESM bajo demanda]
H --> I[HMR y source maps]
style A fill:#89b4fa,color:#11111b
style G fill:#a6e3a1,color:#11111b
style I fill:#f9e2af,color:#11111b

Ese modo servido se apoya en dos piezas más. El HMR (Hot Module Replacement) sustituye un módulo en caliente sin recargar la página, preservando el estado de la interfaz; el módulo declara cómo aceptar la actualización.

// El modulo se auto-parchea sin recargar la pagina entera
if (import.meta.hot) {
  import.meta.hot.accept((nuevo) => aplicar(nuevo));
}

Y los source maps mantienen un mapa desde el código transformado y minificado de vuelta a tu fuente original, para que cuando depures veas tu TypeScript y no un amasijo de una sola línea. Sin source maps, todo lo que gana la optimización lo perderías en cuanto tuvieras que buscar un bug.