El panorama de herramientas en 2026

El error más común al montar un monorepo en 2026 es tratar “las herramientas de monorepo” como una sola caja y preguntarse cuál elegir, cuando en realidad hay dos capas distintas que hacen cosas ortogonales. Abajo, la capa del workspace —pnpm— resuelve el grafo de paquetes, enlaza node_modules y selecciona qué construir. Encima, la capa de orquestación —Turborepo o Nx— modela el grafo de tareas, hashea sus entradas y reutiliza sus salidas. No compiten: se componen. Entender dónde termina una y empieza la otra es lo que convierte un puñado de herramientas en una arquitectura.

Dos capas que no hay que confundir

Toda la confusión se disuelve al dibujar la pila. La capa de abajo gestiona dependencias y enlace: qué versiones se instalan, cómo se materializa node_modules, cómo se enlazan los paquetes internos. La capa de arriba gestiona trabajo: qué tareas hay que correr, en qué orden, cuáles ya se hicieron y no hace falta repetir. pnpm no cachea salidas de tareas; Turborepo y Nx no gestionan node_modules. Cada una ignora deliberadamente lo que hace la otra.

flowchart TD
DEV[tu codigo y tus scripts] --> ORCH[capa de tareas Turborepo o Nx]
ORCH --> PKG[capa de workspace pnpm]
PKG --> FS[node_modules store y symlinks]
ORCH -.-> RC[remote cache reutilizado entre CI y equipo]
style ORCH fill:#89b4fa,color:#11111b
style PKG fill:#a6e3a1,color:#11111b
style RC fill:#cba6f7,color:#11111b

Un ejemplo hace tangible la composición. pnpm declara el workspace; Turbo o Nx declaran las tareas encima; ninguno pisa al otro y cada archivo habla de su capa:

# pnpm-workspace.yaml  (capa de workspace: paquetes y linking)
packages: ["apps/*", "packages/*"]

// turbo.json  (capa de tareas: dependencias entre tareas y outputs)
{ "tasks": { "build": { "dependsOn": ["^build"], "outputs": ["dist/**"] } } }

La composición es literal: instalas con pnpm, orquestas con Turbo o Nx, y cada turbo run build o nx build acaba invocando los scripts que pnpm dejó disponibles. Confundir las capas lleva a preguntas mal planteadas —“¿pnpm o Turborepo?”— cuando la respuesta casi siempre es “pnpm y uno de los dos”. La única elección real de la capa de abajo es pnpm frente a npm, yarn o bun workspaces; la de la capa de arriba es Turborepo frente a Nx —o nada, si el repo aún es pequeño.

Hay una prueba sencilla para saber a qué capa pertenece un problema: si tu dolor es “se instala mal”, “hay dos versiones de React” o “no encuentro un paquete”, es de la capa de workspace; si es “el build tarda”, “el CI recompila lo que no cambió” o “quiero compartir resultados entre máquinas”, es de la capa de tareas. Clasificar el síntoma en la capa correcta es la mitad de resolverlo, y evita el error de buscar la solución en la herramienta equivocada.

La capa de workspace: pnpm en 2026

pnpm es el estándar de facto de la capa inferior, y por buenas razones técnicas. Su store direccionado por contenido guarda cada versión de cada paquete una sola vez en disco y la enlaza por hard link a cada proyecto, así que diez apps que usan la misma versión de React ocupan el espacio de una. Su node_modules estricto —sin hoisting mentiroso— impide las dependencias fantasma: solo puedes importar lo que declaraste. Y para el monorepo aporta el protocolo workspace:, los --filter para actuar sobre subgrafos y los catalogs para la política de versión única.

pnpm --filter "@acme/web..." build      # web y todo de lo que depende
pnpm --filter "...@acme/utils" test      # utils y todo lo que depende de el
pnpm --filter "...[origin/main]" build    # solo lo cambiado desde main

Ese último --filter merece atención: pnpm sí sabe seleccionar por git qué paquetes cambiaron desde un ref, un primo pobre del “affected”. Lo que no hace es recordar si la salida de una tarea ya se calculó. Selecciona y ordena; no memoiza. Junto a los catalogs —una versión central referenciada con catalog: desde cada paquete— y a packageManager con corepack para clavar la propia versión de pnpm, la capa inferior queda cubierta: resolución reproducible, enlace eficiente y selección topológica. La velocidad de “no repetir trabajo” es, por diseño, tarea de la capa de arriba.

La capa de tareas: Turborepo y Nx

Aquí viven las dos grandes opciones, y difieren en filosofía más que en objetivo.

Turborepo encarna el principio de mínima intrusión. Describes en turbo.json cómo se relacionan las tareas —“el build de un paquete depende del build de sus dependencias”— y Turbo se encarga de hashear, cachear y paralelizar respetando la topología. No te pide reestructurar el repo ni adoptar generadores: envuelve los scripts que ya tienes. Es la opción natural para un monorepo con pnpm que solo quiere dejar de recompilar lo que no cambió.

// turbo.json
{
  "tasks": {
    "build": { "dependsOn": ["^build"], "outputs": ["dist/**"] },
    "test": { "dependsOn": ["build"] }
  }
}

Con eso, la segunda corrida sin cambios no ejecuta nada: reproduce salidas y logs desde la caché.

$ turbo run build      # segunda vez, sin cambios
 Tasks: 12 successful, 12 total
 Cached: 12 cached, 12 total    FULL TURBO en 180ms

Nx apuesta por lo contrario: más estructura a cambio de más poder. Infiere un grafo de proyecto detallado, trae generadores y executors para estandarizar cómo se crean y construyen los paquetes, hace cumplir fronteras de módulo con etiquetas, y en Nx Cloud ofrece no solo caché remota sino ejecución distribuida —repartir las tareas de un pipeline entre varias máquinas efímeras—. A cambio pide adoptar sus convenciones. Brilla en organizaciones grandes, repos poliglota y equipos que quieren una plataforma, no solo una caché. Ambas, por cierto, movieron su núcleo de hashing y grafo a Rust en la ola de reescrituras de 2025-2026.

El multiplicador de ambas es el remote caching. La caché local ya evita que tú repitas trabajo; la remota evita que lo repita cualquiera. Sube las salidas hasheadas a un almacén compartido —Vercel, Nx Cloud o uno autohospedado en tu propio bucket— de modo que cuando tu CI va a construir un paquete que alguien ya construyó con las mismas entradas, lo descarga en lugar de compilarlo. Es lo que hace que un pipeline de veinte minutos baje a veinte segundos cuando el noventa por ciento del repo no cambió.

# conectar el remote cache: una vez, y el equipo entero lo comparte
turbo login && turbo link       # cache remota gestionada
# o autohospedada, apuntando a tu propio almacen compatible

Cómo elegir en 2026

La decisión se ordena por escala, no por moda. pnpm, siempre: es la capa inferior y no tiene rival práctico salvo preferencias concretas por bun. La capa de tareas se añade cuando duele: mientras el repo tenga pocos paquetes y el CI vaya sobrado, pnpm -r basta y sobra. Como regla de bolsillo:

• Repo pequeño, pocos paquetes: pnpm y pnpm -r, nada más. La caché todavía no duele y añadirla es complejidad prematura.
• Repo mediano que empieza a tardar: pnpm más Turborepo. Envuelve tus scripts, cachea local y remoto, cero reestructuración.
• Organización grande o poliglota: pnpm más Nx, por el grafo de proyecto, los generadores, las fronteras impuestas y la ejecución distribuida.
• Mega-escala hermética multi-lenguaje: Bazel o Buck2, asumiendo a conciencia su coste de adopción.

Una heurística transversal ayuda: añade una capa solo cuando el dolor que resuelve ya lo estés sintiendo. Meter Nx en un repo de cuatro paquetes, o remote caching antes de que el CI duela, es pagar complejidad por adelantado contra un problema que quizá nunca tengas. La pila correcta no es la más completa, es la más pequeña que resuelve tu dolor actual.