Turborepo: minimalismo y lo que no hace por ti

Turborepo es la respuesta minimalista a la pregunta de cómo dejar de recompilar lo que no cambió. No aspira a ser una plataforma ni a modelar tu organización: aspira a envolver los scripts que ya tienes, hashear sus entradas y no repetir su ejecución cuando el resultado sigue siendo válido. Toda su superficie de configuración cabe en un turbo.json de una docena de líneas, y su curva de adopción se mide en minutos. Esa economía de medios es una decisión de diseño, no una carencia: Turborepo hace deliberadamente pocas cosas para hacerlas bien y sin pedirte que cambies cómo trabajas. Elegirlo con criterio exige entender con la misma claridad lo que hace y lo que se niega a hacer.

La filosofía: envolver, no reemplazar

Turborepo parte de una tesis fuerte: tu monorepo ya funciona con pnpm y con los scripts de cada package.json, y lo único que falta es memoria. En vez de reemplazar ese flujo, se coloca encima como una capa fina que lee el workspace que pnpm ya define, descubre las tareas que tus paquetes ya declaran y las orquesta con caché. No introduce un modelo de proyecto propio, no te pide reorganizar carpetas ni reescribir comandos: envuelve lo existente.

flowchart TD
pnpm[pnpm resuelve e instala] --> scripts[tus scripts en package json]
scripts --> turbo[turborepo orquesta y cachea]
turbo -.-> cache[cache local y remota por contenido]
style turbo fill:#89b4fa,color:#11111b
style pnpm fill:#a6e3a1,color:#11111b
style cache fill:#cba6f7,color:#11111b

La consecuencia práctica de esa tesis es la reversibilidad. Como Turborepo no toca la capa de workspace ni convierte tus scripts en artefactos propietarios, quitarlo es tan barato como borrar turbo.json y volver a invocar pnpm -r run build. No hay lock-in estructural: la herramienta es un acelerador enchufable, no un cimiento. Esa propiedad —poder irse sin coste— es la que da tranquilidad para adoptarlo un martes cualquiera sin convocar un comité de arquitectura.

Una superficie de configuración diminuta

El turbo.json es casi todo lo que hay que aprender. Su vocabulario se reduce a un puñado de claves —tasks, dependsOn, inputs, outputs, cache, env— y con ellas se describe el pipeline completo. No hay executors que abstraigan tus comandos, no hay un lenguaje de plantillas, no hay un plugin que inferir. La tarea es, literalmente, el script que ya tenías; Turborepo solo aprende cuándo puede saltárselo.

// turbo.json: la superficie entera cabe aqui
{
  "tasks": {
    "build": { "dependsOn": ["^build"], "outputs": ["dist/**"] },
    "test": { "dependsOn": ["build"], "outputs": [] },
    "lint": {}
  }
}

Esa parquedad tiene un corolario en 2026: el motor de hashing y planificación está escrito en Rust, y un daemon opcional vigila el sistema de archivos para no rehashear el mundo en cada invocación. Turborepo funciona indistintamente sobre pnpm, npm, yarn o bun —no impone gestor— y añade turbo watch para reejecutar tareas afectadas al vuelo. La regla mental es que el turbo.json no es un programa: es la declaración de un grafo de funciones que deben ser deterministas para que memoizarlas sea legítimo.

Lo que Turborepo no hace por ti, a propósito

El otro lado de la frugalidad es una lista clara de responsabilidades que Turborepo declina. No son huecos por hacer: son fronteras trazadas para no acoplar lo que debe permanecer separado.

Conviene tabular la frontera, porque discutir a Turborepo por lo que no hace es discutirlo por su propia tesis. La columna izquierda es su promesa; la derecha, lo que a conciencia delega en otras capas.

Hay dos ausencias que merecen matiz porque a veces se esperan y no están. La primera es la ejecución distribuida entre varias máquinas efímeras —repartir un pipeline en un enjambre de agentes—: Turborepo cachea de forma remota, pero no orquesta ese reparto como sí hace Nx Cloud. La segunda son las fronteras de módulo: existe un boundaries experimental, pero imponer arquitectura no es su terreno natural. Pedirle cualquiera de las dos es pedirle que deje de ser Turborepo.