Nx vs una configuración a mano

Nx es poderoso, y el poder tiene precio. Su inferencia, sus plugins, sus generadores, sus migraciones y su distribución en la nube resuelven problemas reales de escala, pero introducen abstracción, curva de aprendizaje y acoplamiento a un framework. La pregunta madura no es “¿es Nx bueno?” —lo es— sino “¿tengo el problema que Nx resuelve?”. Este nivel cierra el bloque con un marco para decidir con criterio: cuándo el poder de Nx compensa su complejidad, cuándo basta con algo más ligero, y por qué una de sus propiedades —el aislamiento de caché por rama— importa tanto por seguridad como por velocidad.

El coste real de Nx

Empecemos por lo que a menudo se calla. Una configuración a mano —workspaces de tu package manager más un puñado de scripts— tiene una virtud enorme: es transparente. No hay inferencia mágica, no hay un grafo que se calcula solo, no hay plugins que añaden targets que no escribiste. Lo que ves en los package.json es exactamente lo que pasa. Esa transparencia tiene un techo bajo de escala, pero por debajo de ese techo es difícil de batir en simplicidad.

El problema de la configuración a mano nunca es cómo se ve el primer día, sino cómo envejece. El día uno, tres scripts encadenados son legibles y honestos. El día trescientos, esos scripts han acumulado casos especiales, órdenes frágiles y comentarios que advierten de no tocar tal línea, y nadie recuerda por qué. La transparencia inicial se ha convertido en un artefacto histórico que solo su autor entiende a medias. Ese es el eje sobre el que gira toda la comparación de este nivel: no cuál es más simple hoy, sino cuál degrada mejor bajo la presión del crecimiento.

Nx cobra su poder en varias monedas. Hay una curva de aprendizaje: entender el project graph, los inputs, los executors y los plugins lleva tiempo. Hay abstracción: cuando la inferencia hace aparecer un target, hay que saber de dónde salió para depurarlo. Hay acoplamiento: adoptas un modelo de plugins y una devkit, y salir de ahí no es gratis. Y hay una forma de confianza que hay que ganar: la inferencia y la caché son correctas casi siempre, pero cuando fallan lo hacen de maneras que exigen entender la maquinaria por debajo.

Para hacer tangible el intercambio, compara las dos formas de orquestar un monorepo. A mano, el orden y la selección de lo que corre son tuyos y viven en scripts que hay que mantener; con Nx, describes propiedades y el grafo decide.

// package.json raiz: orquestacion a mano, fragil y explicita
{
  "scripts": {
    "build": "npm run build -w util && npm run build -w ui && npm run build -w web",
    "test": "npm run test -w util && npm run test -w ui && npm run test -w web"
  }
}

El script funciona con tres proyectos. Con treinta se vuelve ingobernable: el orden hay que actualizarlo a mano en cada cambio de dependencias, no hay forma de correr solo lo afectado, y cada tarea se recomputa siempre. La equivalencia en Nx no crece con el repo, porque no enumera proyectos: describe la política una vez.

# Lo mismo, pero el grafo decide orden y alcance
nx run-many -t build
nx affected -t test

Cuándo compensa: escala y grafo

El poder de Nx se paga por adelantado y se cobra en escala. Su valor crece con dos variables: el número de proyectos y la densidad de dependencias cruzadas entre ellos. Sin esas dos cosas, casi todo lo que Nx ofrece queda inerte.

Piénsalo función por función. El affected solo ahorra si hay muchos proyectos y un cambio típico toca a pocos; con tres proyectos, testearlos todos no duele. La caché remota solo brilla si el trabajo es caro y se repite entre personas; en un repo pequeño la caché local basta. La distribución solo hace falta si una máquina no da abasto. Los generadores solo pagan si creas proyectos a menudo y quieres consistencia entre muchos. Todas las capacidades de Nx presuponen un grafo grande y activo; sin él, son respuestas a preguntas que no te estás haciendo.

Vista por capacidades, la progresión es clara: cada escalón añade poder y coste sobre el anterior, y elegir bien es quedarse en el escalón que tu repo de verdad pisa.

La comparación con Turborepo es la más útil porque ambos resuelven el núcleo —caché por hash de inputs y ejecución guiada por el grafo— pero con filosofías distintas. Turborepo es más ligero y explícito: configuras y ves. Nx es más completo y más automático: infiere y mantiene. La elección honesta depende de cuánta de la maquinaria de Nx vas a usar de verdad. Si solo quieres caché y affected, Turborepo te da el noventa por ciento del beneficio con una fracción del peso. Si vas a explotar generadores, migraciones, plugins de inferencia y distribución, el peso de Nx se amortiza y Turborepo se te quedaría corto.

flowchart TD
Q1{muchos proyectos con deps cruzadas} -->|no| M[scripts a mano]
Q1 -->|si| Q2{usaras generadores plugins y migraciones}
Q2 -->|no| T[turborepo cache y affected]
Q2 -->|si| N[nx completo]
style M fill:#a6e3a1,color:#11111b
style T fill:#89b4fa,color:#11111b
style N fill:#cba6f7,color:#11111b

Hay un matiz que la tabla esconde: Nx y Turborepo han ido convergiendo. Turborepo ganó potencia y Nx redujo su ceremonia con la inferencia por plugins, de modo que la frontera de 2026 es menos nítida que hace unos años. Por eso el criterio útil no es cuál es más potente en abstracto —Nx lo es— sino cuánta de esa potencia extra vas a convertir en valor real. Poder que no ejerces es solo coste que pagas.

Nada de esto es un juicio moral sobre las herramientas: es un ajuste entre problema y solución. La mejor herramienta es la que corresponde a la escala que tienes hoy y a la que tendrás pronto, ni una más pesada por aspiración ni una más ligera por inercia.

Esa correspondencia entre problema y solución es justo lo que el resto del nivel te ayuda a calibrar, empezando por una propiedad que rara vez aparece en las comparativas de rendimiento pero que a escala decide tanto como la velocidad: la seguridad de la caché compartida.

Caché por rama: seguridad, no solo velocidad

Hay un factor que suele quedar fuera del cálculo coste-beneficio y que a escala se vuelve decisivo: la seguridad de la caché compartida. Cuando decides adoptar caché remota, estás creando un almacén de artefactos que muchas personas escriben y muchas máquinas ejecutan. Eso no es solo una optimización de rendimiento; es una nueva superficie de ataque.

El aislamiento de caché por rama que viste en la lección de Nx Cloud es la respuesta a ese riesgo. Impide que un artefacto producido en una rama cualquiera se replique hacia una rama protegida y sea ejecutado como bueno —el envenenamiento de caché que el CVE CREEP de 2025 volvió tangible—. Y aquí está el punto para tu marco de decisión: a escala, la caché compartida deja de ser opcional, porque sin ella el CI no aguanta; pero hacer una caché compartida segura es difícil, y equivocarse convierte tu acelerador en un vector de compromiso. Que una plataforma resuelva el aislamiento por ti no es un extra: es parte de lo que compensa el coste de adoptarla, porque el aislamiento hecho a mano es exactamente el tipo de trabajo de infraestructura que nadie quiere mantener.

Hay una simetría que cierra el argumento: las mismas dos propiedades que vuelven valioso a Nx a escala —la caché compartida y la distribución— son las que introducen el riesgo de envenenamiento. No puedes quedarte solo con el beneficio; adoptar la caché compartida es adoptar también su superficie de ataque, y por tanto la necesidad de aislarla. Que la plataforma resuelva ese aislamiento por defecto convierte un problema de seguridad difícil en una casilla ya marcada, y eso, en sí mismo, es una razón de peso para no reimplementar la caché a mano.

Un marco de decisión

Traducido a preguntas concretas, el juicio se vuelve manejable. Ninguna respuesta suelta decide; es el patrón conjunto el que inclina la balanza hacia más o menos maquinaria.

La última fila es la que más se olvida y la que a escala pesa tanto como las demás: quién puede escribir en la caché que tus máquinas ejecutan. Si vas a compartirla entre mucha gente, el aislamiento por rama deja de ser un lujo y se vuelve un requisito, y que una plataforma lo resuelva por ti entra de lleno en el cálculo de si compensa adoptarla.

Aplica el marco con honestidad sobre tu caso real, no sobre el caso ideal de la documentación. La mayoría de los repositorios del mundo no son el monorepo de una gran tecnológica con miles de proyectos; son repos medianos donde la respuesta correcta a menudo es Turborepo, o incluso scripts a mano bien cuidados. Nx brilla en el extremo alto de la escala, y reconocer si estás en ese extremo —o si de verdad te diriges hacia él— es la mitad de la decisión.

La otra mitad es aceptar que no hay una respuesta permanente. El veredicto correcto para tu repo de hoy puede no serlo dentro de un año, y la madurez consiste en revisar la elección con la misma frialdad con la que la tomaste, sin lealtad a la herramienta ni miedo a migrar cuando los números lo pidan.

Y si tras el análisis sigues dudando, esa duda es información: significa que estás cerca de la frontera, donde coste y beneficio casi se igualan. En la frontera, elige lo más simple que cubra tu año próximo, porque siempre es más barato subir de escalón cuando el dolor llega que arrepentirse de uno que nunca necesitaste.