Arquitectar el build de un producto a escala

Llegas aquí sabiendo cada pieza por separado: pnpm y su store, Vite y sus dos naturalezas, el bundler Rolldown sobre Oxc, el empaquetado de librerías, el monorepo con Turborepo, la caché remota, el code splitting y el deploy al edge. Arquitectar no es conocer más piezas: es componerlas en un sistema donde cada decisión restringe y habilita a la siguiente. Un build de producto a escala no es una lista de herramientas, sino una cadena de compromisos que empieza en la raíz del repositorio y termina en un CDN a milisegundos del usuario. Esta lección traza ese mapa entero y te enseña a recorrerlo como cadena, no como inventario.

Cinco capas, una sola cadena

La tentación al empezar un proyecto es elegir herramientas por separado —“uso pnpm, Vite y Vercel”— como si fueran platos de un bufé independientes. No lo son. Cada elección estrecha el abanico de la siguiente, y las decisiones tempranas son las que más pesan porque las heredan todas las capas de arriba. Arquitectar bien es reconocer ese acoplamiento y decidir en el orden correcto: de la raíz hacia el edge, no al revés.

El camino de src a producción atraviesa cinco capas, y cada una responde una pregunta distinta:

• Estructura del repo — ¿un solo paquete o muchos? Monorepo con workspaces o polyrepo. Esta decisión gobierna todo lo demás.
• Instalación y resolución — ¿qué package manager y qué node-linker? pnpm con su store enlazado, catalogs para unificar versiones, frozen-lockfile en CI.
• Desarrollo — ¿qué dev server y qué motor? Vite sobre Rolldown, HMR, la Environment API cuando hay SSR.
• Empaquetado — ¿qué produce el build? tree shaking, code splitting por ruta, minificación, hashing de assets, budgets.
• Orquestación y deploy — ¿cómo evitas repetir trabajo y dónde corre? Turborepo con caché remota, CI con provenance, deploy al edge.

flowchart TD
repo[Estructura del repo: monorepo o polyrepo] --> inst[Instalacion: pnpm store y catalogs]
inst --> dev[Desarrollo: Vite sobre Rolldown]
dev --> bundle[Empaquetado: tree shaking splitting budgets]
bundle --> orq[Orquestacion: Turborepo y cache remota]
orq --> edge[Deploy al edge]
repo -.restringe.-> orq
style repo fill:#cba6f7,color:#11111b
style edge fill:#a6e3a1,color:#11111b
style orq fill:#89b4fa,color:#11111b

Fíjate en la arista punteada: la estructura del repo no solo condiciona la instalación, sino que salta hasta la orquestación. Elegir monorepo obliga a tener una capa de caché por tareas; elegir polyrepo la vuelve innecesaria pero fragmenta las versiones. Ninguna capa se decide sola.

Las decisiones que restringen

Cuatro decisiones tempranas fijan el carácter de todo el sistema. Tómalas mal y pasarás el resto del proyecto compensando; tómalas bien y las capas de arriba caen por su propio peso.

El presupuesto como brújula

A escala, la métrica que importa deja de ser “compila rápido” y pasa a ser doble: no compilar lo que no cambió y no enviar al navegador lo que no se usa. Son las dos caras de la misma disciplina de frugalidad, y las dos se declaran, no se esperan.

Del lado del build, la frugalidad es la caché por tareas. Turborepo hashea las entradas de cada tarea —archivos, dependencias, variables— y, si nada cambió, replica la salida en milisegundos en vez de recompilar. La condición es declarar con precisión qué entra y qué sale.

// turbo.json: la caja de una tarea, declarada para que el hash sea fiable
{
  "tasks": {
    "build": {
      "dependsOn": ["^build"],
      "inputs": ["src/**", "package.json", "tsconfig.json"],
      "outputs": ["dist/**"]
    }
  }
}

Del lado del cliente, la frugalidad es el presupuesto de bundle. Un budget convierte una intención vaga —“que cargue rápido”— en un límite que el CI hace cumplir, de modo que una dependencia pesada colada sin querer rompe el build en vez de degradar en silencio la experiencia del usuario.

// Un limite duro: el CI falla si el chunk de entrada crece de mas
export default {
  build: {
    chunkSizeWarningLimit: 200,
    rollupOptions: { output: { manualChunks: { vendor: ['react', 'react-dom'] } } }
  }
}

Del commit al edge

La última capa cierra la cadena: el mismo trabajo hasheado que evita recompilar en tu máquina viaja a CI por la caché remota, y de CI sale un artefacto firmado que se despliega al edge. Cada capa hereda las garantías de la anterior, y cada capa tiene su modo de fallo característico.

Leer esta tabla de arriba abajo es leer la cadena entera. Un problema en producción casi nunca vive donde se manifiesta: un bundle inflado suele nacer de una librería mal empaquetada tres capas más abajo, y un build irreproducible en CI suele nacer de un lockfile no congelado en la capa de instalación. Diagnosticar a escala es saber recorrer la cadena hacia atrás.