Vendor splitting y dedupe: dependencias cacheables sin duplicados

Tu código cambia cada día; tu framework, cada pocas semanas. Mezclar ambos en un mismo chunk es tirar caché a la basura: cada corrección de una línea tuya invalida también todos los bytes de las librerías, obligando al usuario a redescargarlas. Separar las dependencias de terceros en un vendor chunk aprovecha su lentitud de cambio para que sobreviva en la caché del navegador a decenas de tus despliegues. Pero esa estrategia tiene un enemigo silencioso que la corroe desde dentro: la duplicación. Cuando la misma librería aparece dos veces en el grafo, no solo pagas sus bytes dos veces —a veces rompes la aplicación—. Este nivel es sobre las dos caras de la misma moneda: separar bien lo cacheable y eliminar lo que sobra.

Separar el vendor para la caché

Rolldown extrae código común por defecto, pero el vendor merece una regla explícita porque quieres controlar su granularidad. La API moderna de Vite 8 es advancedChunks, que define grupos por un test sobre la ruta del módulo, con umbrales de tamaño para evitar chunks minúsculos. La forma clásica manualChunks, una función que devuelve el nombre del chunk, sigue soportada por compatibilidad.

// vite.config.ts — vendor subdividido por familia con advancedChunks
import { defineConfig } from "vite";

export default defineConfig({
  build: {
    rollupOptions: {
      output: {
        advancedChunks: {
          minSize: 20_000,
          groups: [
            { name: "vendor-react", test: /node_modules\/(react|react-dom)\// },
            { name: "vendor-charts", test: /node_modules\/(d3|visx)\// },
            { name: "vendor", test: /node_modules\// },
          ],
        },
      },
    },
  },
});

El orden importa: el primer grupo cuyo test casa gana, así que las familias específicas van antes que el vendor genérico que recoge el resto. Aíslas lo grande y volátil —el framework, la librería de gráficas— en chunks propios y fundes lo demás en un vendor común. La razón es la caché: cuando actualizas una sola librería, solo cambia el hash de su chunk, y el navegador reutiliza todos los demás. Un vendor monolítico invalidaría el bloque entero por una sola actualización.

Cazar duplicados en el grafo

El vendor bien separado se envenena si la misma dependencia entra dos veces. Ocurre por la resolución de versiones: el paquete A pide util@^4.0 y el paquete B pide util@^4.2, y si los rangos no convergen en una única versión instalada, el gestor deja dos copias en node_modules bajo rutas distintas. El bundler, fiel al grafo, empaqueta ambas. En el treemap las ves como dos bloques gemelos con el mismo nombre.

flowchart TD
app[Tu aplicacion] --> a[libreria A pide util 4.0]
app --> b[libreria B pide util 4.2]
a --> u1[copia util 4.0]
b --> u2[copia util 4.2]
u1 -. mismo paquete dos veces .- u2
style u1 fill:#f38ba8,color:#11111b
style u2 fill:#f38ba8,color:#11111b

La primera herramienta es el gestor de paquetes. pnpm why util te dice quién pide cada versión y por qué conviven; pnpm dedupe reescribe el árbol para colapsar copias compatibles en una sola, y pnpm dedupe --check falla en CI si quedan duplicados evitables. Cuando dos rangos son irreconciliables y ninguno cede, fuerzas la mano con un override, que impone una versión única a todo el árbol.

// package.json — forzar una unica version en todo el grafo con pnpm
{
  "pnpm": {
    "overrides": {
      "util": "4.2.0"
    }
  }
}

// vite.config.ts — colapsar singletons a una sola instancia
export default defineConfig({
  resolve: {
    dedupe: ["react", "react-dom"],
  },
});

Singletons: cuando duplicar es un bug

Para la mayoría de librerías, un duplicado es solo peso desperdiciado. Pero para una clase especial —los singletons con estado— es un fallo de corrección. React es el ejemplo canónico: su sistema de hooks y de contexto depende de que haya una única instancia del módulo en toda la aplicación. Con dos copias, un componente registra su contexto en una y otro lo lee de la otra; el valor no aparece, los hooks lanzan errores crípticos sobre múltiples versiones, y el bug no se parece en nada a un problema de tamaño.

La raíz es que un módulo no es solo código: es también identidad. Dos copias de un módulo con estado son dos universos que no se ven entre sí, cada uno con su propio store, su propio contexto, su propio registro. Por eso las librerías que son singletons se declaran como peerDependencies —“no me empaquetes tú, usa la del anfitrión”— y por eso deduplicarlas no es una optimización opcional sino una condición para que la aplicación funcione.