Criterios para elegir tu build system
Elegir build system no es rankear herramientas sino situar tu problema en un espacio de varios ejes: el tamano y la estructura del equipo, el tipo de proyecto y su poliglotismo, el apetito de configuracion que tolera tu gente, y el ecosistema que ya te rodea. Ninguna herramienta gana en abstracto; cada una es optima en una region concreta de ese espacio. Este es un marco de decision para pasar de la moda al criterio, con una tabla, un arbol y una heuristica transversal que evita tanto sobredimensionar como quedarse corto.
La pregunta cuál es el mejor build system está mal formulada, y reformularla es media lección. No existe un ganador en abstracto porque estas herramientas no compiten en una escala única de bondad: cada una es óptima en una región de un espacio de varios ejes. Elegir bien, por tanto, no es encontrar la herramienta superior sino situar tu problema en ese espacio y leer qué pieza fue diseñada para tu región. Los ejes que importan son cuatro: el tamaño y la forma de tu equipo, el tipo de proyecto que construyes, el apetito de configuración que tu gente tolera, y el ecosistema que ya te rodea. Este es un marco para pasar de decidir por moda a decidir por criterio.
- Sustituir la pregunta del mejor por la de la región del espacio donde vive tu problema.
- Ponderar los cuatro ejes: equipo, tipo de proyecto, apetito de configuración y ecosistema.
- Aplicar un marco de decisión —tabla y árbol— para convertir esos ejes en una elección.
- Interiorizar la heurística de añadir capa solo cuando el dolor ya se siente.
Elegir no es rankear: es ubicar tu problema
El primer reflejo a desmontar es el del ranking. Cuando alguien pregunta si Turborepo es mejor que Nx, o si Moon supera a ambos, está tratando un espacio multidimensional como si fuera una recta. Pero una herramienta que es óptima para un equipo de tres con un repo de puro TypeScript puede ser una carga absurda para una organización poliglota de doscientos ingenieros, y viceversa. No hay contradicción: son regiones distintas del mismo espacio, y cada herramienta habita la suya.
De ahí que la única elección estable de la capa inferior sea pnpm —el sustrato que casi nadie debería cambiar— y que toda la discusión real ocurra en la capa de orquestación, que además es reversible. Como esa capa es ortogonal al workspace, equivocarse de orquestador es un error barato de corregir; equivocarse de marco mental para elegirlo es el error caro, porque se repite en cada decisión.
Como el orquestador se apoya sobre pnpm sin absorberlo, cambiarlo mañana no toca tu pnpm-workspace.yaml ni tus paquetes. Eso rebaja el drama de la elección: no estás tallando en piedra una arquitectura para diez años, estás eligiendo la capa más pequeña que resuelve tu dolor de hoy, con la tranquilidad de poder revisarla cuando el dolor cambie. Decidir tarde y barato es una estrategia legítima, no una indecisión.
Los cuatro ejes de la decisión
Cada eje empuja la elección en una dirección. La destreza está en leer los cuatro a la vez, no en absolutizar uno.
Tamaño y forma del equipo
Pocas personas y un solo equipo favorecen lo minimalista: menos que aprender, menos que mantener. Muchas personas y varios equipos favorecen la plataforma: la consistencia impuesta vale más que la libertad.
Tipo de proyecto
Puro JavaScript o TypeScript encaja con Turborepo o Moon. Poliglota —varios lenguajes en el mismo repo— empuja hacia Nx; la necesidad de hermetismo extremo, hacia Bazel o Buck2.
Apetito de configuración
Un equipo que quiere resultados sin ceremonia elige la superficie diminuta de Turborepo. Uno dispuesto a adoptar convenciones a cambio de poder tolera —y aprovecha— la plataforma de Nx.
Ecosistema alrededor
El framework, el proveedor de CI y de caché remota, y las integraciones que ya usas inclinan la balanza: Turborepo se alinea con el mundo Vercel; Nx trae su propio universo de plugins; Moon, su toolchain con proto.
El eje del ecosistema se subestima y suele decidir en la práctica. Si ya despliegas en Vercel, la caché remota gestionada de Turborepo es un enchufe; si tu organización ya vive de plugins de Nx para sus frameworks, salir de ahí cuesta; si tu dolor es la divergencia de versiones de runtime, el toolchain gestionado de Moon resuelve algo que los otros dos te dejan a mano. El ecosistema no es un detalle secundario: a menudo es la fricción real que hace que una elección teóricamente empatada se decante.
El fallo recurrente es dejar que un solo eje mande. Elegir Nx solo porque el repo es grande, ignorando que es de puro TypeScript y que el equipo no quiere aprender executors, lleva a una plataforma infrautilizada. Elegir Turborepo solo por minimalismo, ignorando que el repo es poliglota y que el CI en serie ya dura una hora, deja poder sobre la mesa. La elección buena es la resultante de los cuatro vectores, no la proyección sobre el que más ruido hace.
Un marco de decisión
Con los ejes en mano, la decisión se puede sistematizar. La tabla mapea perfiles de repositorio a la pila más pequeña que los resuelve; el árbol la convierte en un recorrido.
| Perfil del repositorio | Pila recomendada |
|---|---|
| pocos paquetes, el CI va sobrado | pnpm y pnpm -r, sin orquestador |
| mediano de JS o TS que empieza a tardar | pnpm más Turborepo |
| divergencias de runtime entre máquinas | pnpm más Moon, por el toolchain gestionado |
| organización grande o poliglota | pnpm más Nx, por grafo, generadores y distribución |
| mega-escala hermética multi-lenguaje | Bazel o Buck2, asumiendo su coste |
flowchart TD start[cuantos paquetes y cuanto duele el CI] -->|pocos y no duele| solo[pnpm a secas] start -->|empieza a doler| tipo[que tipo de repo es] tipo -->|js o ts homogeneo| turbo[turborepo] tipo -->|runtime divergente| moon[moon con proto] tipo -->|grande o poliglota| nx[nx] tipo -->|hermetico mega escala| bazel[bazel o buck2] style turbo fill:#89b4fa,color:#11111b style nx fill:#cba6f7,color:#11111b style moon fill:#a6e3a1,color:#11111b
Sobre este marco actúa una heurística transversal que vale más que cualquier casilla concreta: 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 ni la más admirada, es la más pequeña que resuelve tu dolor actual; cada capa que añades debe justificarse por un dolor presente, no por uno hipotético.
La madurez al elegir un build system se reconoce en una sola cosa: haber dejado de buscar el mejor y haber empezado a preguntar dónde vive mi problema. Quien piensa en rectas pide recomendaciones absolutas —dime cuál uso— y colecciona opiniones contradictorias, porque cada persona responde desde la región del espacio que ella habita, y todas tienen razón en su región. Quien piensa en espacios entiende que la respuesta correcta es una función de coordenadas: el tamaño y la forma del equipo, el tipo y el poliglotismo del proyecto, el apetito de configuración de la gente, y el ecosistema que ya lo rodea. Fijadas esas coordenadas, la elección casi se despeja sola, porque cada herramienta fue diseñada para ser óptima en una región y basta con leer en cuál caes. Y hay una segunda mitad del criterio, tan importante como la primera: la humildad de no ubicarte en una región más exigente de la que estás. La tentación de elegir la herramienta más potente por si acaso, de montar la plataforma que usan las grandes organizaciones en un repo de diez paquetes, es la forma más común de arruinar un monorepo, porque paga entero el coste de una capacidad cuyo beneficio no cobrará hasta una escala que quizá no alcance nunca. El criterio completo, entonces, es doble: sitúa tu problema en el espacio con honestidad sobre dónde estás hoy, y elige la pieza más pequeña que cubre esa región, ni una más. Todo lo demás —la moda, el entusiasmo por una reescritura en Rust, la envidia de la pila de una empresa famosa— es ruido que empuja a elegir por la razón equivocada. El ingeniero que interioriza esto deja de coleccionar herramientas y empieza a coleccionar coordenadas: sabe leer un repositorio, ubicarlo, y nombrar sin dudar la capa mínima que lo resuelve.
- Escribe las cuatro coordenadas de tu repo actual: tamaño y forma del equipo, tipo de proyecto, apetito de configuración y ecosistema que ya usas.
- Recorre el árbol de decisión con esas coordenadas y anota a qué hoja llegas antes de mirar la tabla.
- Compara tu hoja con la fila de la tabla que mejor describe tu perfil y explica cualquier discrepancia entre ambas.
- Aplica la heurística del dolor: para cada capa que tu elección añade, nombra el dolor presente —no futuro— que la justifica; si no encuentras uno, quítala.
- Redacta en tres líneas la decisión y su porqué, referida a coordenadas y no a modas, de modo que resista la pregunta pero por qué no la herramienta de moda.