Rollup: el bundler ESM-first que definió el modelo

En 2015, cuando webpack ya reinaba, Rich Harris publicó Rollup con una tesis incómoda: los módulos de ES no son un formato de empaquetado más, sino una estructura estática que un bundler puede analizar y aplanar. De esa apuesta —tratar import y export como declaraciones analizables en tiempo de compilación, y no como llamadas resueltas en tiempo de ejecución— nacieron el tree shaking serio y una salida tan limpia que parecía escrita a mano. Rollup no fue un empaquetador más: definió el modelo mental que Vite y Rolldown heredarían una década después.

El giro ESM-first

La idea que lo cambió todo es sutil: en un módulo de ES, import y export son declaraciones estáticas, no instrucciones que se ejecutan. Están siempre en el nivel superior, no dentro de un if, y sus nombres son literales, no cadenas calculadas. Eso significa que un bundler puede leer el archivo, sin ejecutarlo, y saber con certeza qué exporta cada módulo y qué importa de los demás. El grafo completo se conoce por análisis, no por ejecución.

Compáralo con CommonJS. Un require('./' + nombre) es una llamada a función en tiempo de ejecución: puede estar dentro de una condición, recibir una ruta calculada, o envolverse en un try. El bundler no puede saber de antemano qué se carga sin ejecutar el programa. Esa dinámica, cómoda para el autor, le cierra la puerta al análisis estático: si no puedes demostrar qué exports se usan, no puedes eliminar los que no.

La diferencia se resume en qué puede saber el bundler antes de ejecutar una sola línea:

• ESM: import y export viven en el nivel superior, con nombres literales y analizables en el parseo.
• CommonJS: require es una llamada en runtime, con rutas calculables y ramas condicionales.
• Consecuencia: solo con ESM el grafo y el conjunto de exports usados se conocen por análisis puro.
• Efecto: el tree shaking es honesto sobre ESM e inevitablemente parcial y conservador sobre CommonJS.

Rollup partió de la premisa contraria. Al asumir ESM como formato de primera clase, cada export se convierte en un binding rastreable a lo largo del grafo, y cada import en una arista que el bundler dibuja sin ambigüedad. Sobre esa base estática se apoya todo lo demás: no hay tree shaking honesto sin un grafo que se conozca por completo antes de generar una sola línea de salida.

Salida plana: scope hoisting y tree shaking

Con el grafo conocido, Rollup hace dos cosas que definieron su firma. La primera es el tree shaking: recorre el grafo desde los puntos de entrada, marca qué exports se alcanzan de verdad, y descarta el resto. No es minificación —eso viene después—, sino eliminación de código muerto a nivel de export, algo que solo es posible porque los bindings son estáticos.

La segunda es el scope hoisting. En vez de envolver cada módulo en una función y coserlos con un require interno, Rollup fusiona todos los módulos en un único ámbito compartido, renombrando lo que colisione. El resultado no lleva runtime: ni __require, ni tabla de módulos, ni closures por archivo. La salida se parece a lo que habrías escrito a mano si hubieras juntado todo tú mismo.

Son dos operaciones distintas encadenadas sobre el mismo grafo conocido:

• Tree shaking: recorre desde los puntos de entrada y descarta los exports que no se alcanzan.
• Scope hoisting: fusiona los módulos supervivientes en un solo ámbito, renombrando lo que colisione.
• Resultado: ni runtime, ni tabla de módulos, ni closures por archivo; código plano y depurable.

// utilidades.js
export function usada() { return 1 }
export function ignorada() { return 2 }

// main.js
import { usada } from './utilidades.js'
console.log(usada())

Rollup analiza que ignorada no se alcanza desde la entrada, la elimina, y aplana los dos módulos en uno solo:

// bundle.js
function usada() { return 1 }
console.log(usada());

No queda rastro de ignorada, no hay envoltura de módulo, no hay coste de arranque. Esa transparencia importa: el bundle es depurable a simple vista, y el consumidor no paga por lo que no usa. Frente al artefacto de webpack de la época —correcto, pero cargado de andamiaje— la diferencia era visible en el primer vistazo al archivo generado.

flowchart TD
E[modulos ESM con imports estaticos] --> A[analisis estatico del grafo]
A --> T[tree shaking elimina exports sin usar]
T --> H[scope hoisting fusiona en un scope]
H --> O[salida plana y legible sin runtime]

Por qué brilló en librerías

Una aplicación y una librería tienen necesidades opuestas, y ahí se explica todo. Una app quiere un dev server, HMR, carga de imágenes y CSS, y un code splitting agresivo para su enrutado: el territorio donde webpack era imbatible. Una librería quiere justo lo contrario —cero runtime propio, un artefacto minúsculo, salida en varios formatos para cualquier consumidor, y que el que la instale pueda a su vez hacer tree shaking de lo que no toque—. Rollup daba exactamente eso.

Esa especialización tuvo una consecuencia histórica curiosa: aunque Rollup nació como bundler de librerías, Vite lo reclutó después como su empaquetador de aplicaciones, envolviéndolo con el code splitting y la gestión de assets que una app necesita. El bundler pensado para publicar terminó siendo, bajo la orquestación de Vite, el motor de producción de medio ecosistema de aplicaciones. La misma calidad de salida que lo hizo ideal para redistribuir resultó igual de valiosa para desplegar.

Por eso el catálogo de proyectos que lo adoptaron es un quién es quién de las librerías del frontend: React, Vue, D3, three.js, Svelte y buena parte de npm publicaron con Rollup. Su salida plana era ideal para redistribuir; su capacidad de emitir esm, cjs y umd en una pasada resolvía el problema de servir a consumidores dispares; y su footprint nulo encajaba con la promesa de una dependencia que no engorda al que la usa.

Las necesidades de una librería explican, punto por punto, por qué el encaje era tan natural:

• Varios formatos: emitir esm, cjs y umd en una sola pasada para consumidores dispares.
• Cero runtime: sin andamiaje que engorde el paquete ni cargue el arranque de quien lo instala.
• Salida legible: un bundle plano que se depura a simple vista y se audita sin fricción.
• Tree shaking heredado: el consumidor final poda lo que no toca, porque el esm preserva la estructura.