{"id":502,"date":"2026-03-09T15:32:16","date_gmt":"2026-03-09T15:32:16","guid":{"rendered":"https:\/\/blog.rebalai.com\/es\/2026\/03\/09\/turborepo-vs-nx-which-monorepo-tool-wont-drive-you\/"},"modified":"2026-03-18T22:31:17","modified_gmt":"2026-03-18T22:31:17","slug":"turborepo-vs-nx-which-monorepo-tool-wont-drive-you","status":"publish","type":"post","link":"https:\/\/blog.rebalai.com\/es\/2026\/03\/09\/turborepo-vs-nx-which-monorepo-tool-wont-drive-you\/","title":{"rendered":"Turborepo vs Nx: Qu\u00e9 Herramienta de Monorepo No Te Volver\u00e1 Loco en 2026"},"content":{"rendered":"

Llevo tres a\u00f1os peleando con monorepos. Empec\u00e9 con un repo gigante de Node.js donde todo viv\u00eda junto, sin ninguna herramienta de build especial, y lleg\u00f3 un momento en que el CI tardaba 23 minutos en correr. No segundos \u2014 minutos. Cada PR era una espera eterna y nadie en el<\/a> equipo sab\u00eda exactamente qu\u00e9 hab\u00eda que tocar para que algo se reconstruyera correctamente.<\/p>\n

Entonces empec\u00e9 a evaluar opciones en serio. La primera semana de febrero us\u00e9 Turborepo 2.3 en un proyecto interno con mi equipo (somos 6 personas, manejamos tres apps de Next.js y cinco paquetes compartidos). La segunda semana migr\u00e9 todo a Nx 20.x con la misma base de c\u00f3digo<\/a>. Misma infra, mismo equipo, mismos problemas de partida.<\/p>\n

Aqu\u00ed est\u00e1 lo que<\/a> encontr\u00e9.<\/p>\n

Por Qu\u00e9 el Monorepo Sin Tooling Se Convierte en un Infierno Pasado Cierto Punto<\/h2>\n

Primero el contexto, porque creo que importa bastante para entender los tradeoffs.<\/p>\n

El proyecto que us\u00e9 para las pruebas es una plataforma SaaS: una app de cliente, un dashboard interno, una API<\/a> en Express y varios paquetes compartidos: @myapp\/ui<\/code>, @myapp\/types<\/code>, @myapp\/utils<\/code>. Setup cl\u00e1sico. Antes de llegar a cualquiera de las dos herramientas, us\u00e1bamos workspaces de pnpm con algunos scripts de bash a mano. Funcionaba, pero “funcionar” y “funcionar bien” son cosas muy distintas.<\/p>\n

El problema m\u00e1s grande no era el tiempo de build \u2014 era que nadie<\/a> sab\u00eda qu\u00e9 depend\u00eda de qu\u00e9. Si alguien tocaba @myapp\/utils<\/code>, el CI corr\u00eda absolutamente todo. Siempre. Sin excepci\u00f3n. No hab\u00eda forma de que el sistema supiera que la app de cliente no importa utils<\/code> para nada. El desarrollador que pusheaba un cambio de tres l\u00edneas esperaba el mismo tiempo que el que hab\u00eda refactorizado medio sistema.<\/p>\n

Eso es lo que<\/a> tanto Turborepo como Nx intentan resolver: dependency graph + cach\u00e9 inteligente. Pero lo hacen de maneras filos\u00f3ficamente distintas, y esa diferencia se siente desde el minuto uno.<\/p>\n

Turborepo 2.3: La Configuraci\u00f3n Te Seduce el Primer D\u00eda<\/h2>\n

La experiencia de onboarding de Turborepo es genuinamente buena. Corr\u00ed npx create-turbo@latest<\/code> y en diez minutos ten\u00eda algo funcional. La configuraci\u00f3n central vive en turbo.json<\/code> y es notablemente legible para alguien que llega sin contexto previo:<\/p>\n

{\n  "$schema": "https:\/\/turbo.build\/schema.json",\n  "tasks": {\n    "build": {\n      "dependsOn": ["^build"],\n      "outputs": [".next\/**", "dist\/**"]\n    },\n    "lint": {\n      "dependsOn": [],\n      "cache": true\n    },\n    "test": {\n      "dependsOn": ["^build"],\n      "cache": true,\n      "outputs": ["coverage\/**"]\n    },\n    "dev": {\n      "persistent": true,\n      "cache": false\n    }\n  }\n}\n<\/code><\/pre>\n
El ^build<\/code> en dependsOn<\/code> es la clave. Significa “primero construye todas mis dependencias”. Simple, declarativo, hace exactamente lo que<\/a> dice. Pas\u00e9 como 30 minutos leyendo la doc y ya ten\u00eda el modelo mental completo. No hubo un momento de “espera, \u00bfc\u00f3mo funciona esto realmente?”<\/p>\n
El cach\u00e9 local funcion\u00f3 de maravilla desde el primer intento. Despu\u00e9s del primer build completo (que tard\u00f3 4 minutos), el segundo tard\u00f3 11 segundos. Exactamente 11. Lo med\u00ed tres veces<\/a> porque no me lo cre\u00eda.<\/p>\n
Lo que me decepcion\u00f3 fue el Remote Cache. La opci\u00f3n oficial es Vercel Remote Cache, gratuita para proyectos<\/a> personales pero con pricing que escala r\u00e1pido para equipos<\/a>. Hay opciones open source \u2014 turborepo-remote-cache<\/code> es un servidor que puedes hostear t\u00fa mismo \u2014 y funciona, pero no es la experiencia pulida que el resto de Turborepo promete. En nuestro caso usamos AWS y pas\u00e9 una tarde completa configurando S3 m\u00e1s el servidor de cach\u00e9. Funciona. Pero es un contraste raro con lo f\u00e1cil que fue todo lo anterior.<\/p>\n
Otra cosa que vale mencionar: Turborepo no tiene opini\u00f3n sobre c\u00f3mo estructuras tus paquetes. No genera nada, no sugiere nada, no impone nada. Eso es un arma de doble filo. Si ya sabes lo que<\/a> est\u00e1s haciendo, tienes control total. Si est\u00e1s armando un monorepo desde cero con un equipo mixto, vas a invertir tiempo extra dise\u00f1ando convenciones que en otras herramientas vienen incluidas.<\/p>\n
Mi conclusi\u00f3n pr\u00e1ctica con Turborepo: te compra tiempo de build, te cuesta tiempo de configuraci\u00f3n de<\/a> infraestructura. El net positivo existe \u2014 es real \u2014 pero no es tan instant\u00e1neo como la demo inicial hace creer.<\/p>\n
Nx 20.x: M\u00e1s Framework que Herramienta, y Eso Tiene Consecuencias<\/h2>\n
Nx es una bestia diferente. La primera se\u00f1al fue el wizard de instalaci\u00f3n: npx create-nx-workspace@latest<\/code> me pregunt\u00f3 si quer\u00eda un “monorepo integrado” o un “standalone project”, qu\u00e9 framework quer\u00eda usar, si quer\u00eda habilitar Nx Cloud, y un par de preguntas m\u00e1s. Hay mucha m\u00e1s superficie desde el principio \u2014 lo cual no es malo, pero te avisa de c\u00f3mo va a ser la relaci\u00f3n.<\/p>\n
El nx.json<\/code> b\u00e1sico se ve as\u00ed:<\/p>\n
{\n  "defaultBase": "main",\n  "targetDefaults": {\n    "build": {\n      "dependsOn": ["^build"],\n      "cache": true,\n      "outputs": ["{projectRoot}\/dist"]\n    },\n    "test": {\n      "cache": true,\n      "outputs": ["{projectRoot}\/coverage"]\n    }\n  },\n  "namedInputs": {\n    "default": ["{projectRoot}\/**\/*", "sharedGlobals"],\n    "sharedGlobals": ["{workspaceRoot}\/tsconfig.base.json"],\n    "production": [\n      "default",\n      "!{projectRoot}\/**\/?(*.)+(spec|test).[jt]s?(x)"\n    ]\n  }\n}\n<\/code><\/pre>\n
Ojo con namedInputs<\/code> \u2014 esto es<\/a> algo que Turborepo no tiene de forma nativa con la misma granularidad. Puedes definir exactamente qu\u00e9 archivos invalidan el cach\u00e9 de cada tarea. En teor\u00eda es poderoso. En la pr\u00e1ctica, tard\u00e9 tres d\u00edas en entender bien c\u00f3mo configurarlo sin romper el cach\u00e9 en situaciones edge. No es que sea dif\u00edcil \u2014 es que hay m\u00e1s piezas que ensamblar correctamente.<\/p>\n
Donde Nx brilla de verdad<\/a> es en el<\/a> grafo de dependencias. nx graph<\/code> abre una visualizaci\u00f3n interactiva en el<\/a> browser que muestra exactamente qu\u00e9 depende de qu\u00e9. La primera vez que lo vi pens\u00e9 “okay, esto justifica el setup m\u00e1s largo”. Con seis paquetes y tres apps, el grafo ya resulta \u00fatil para onboardear a alguien nuevo. Me imagino que con 40 proyectos es directamente indispensable.<\/p>\n
Los generators son otra ventaja concreta. nx generate @nx\/next:app nueva-app<\/code> crea una app con toda la configuraci\u00f3n integrada en el workspace \u2014 tsconfig extendido, configuraci\u00f3n de<\/a> tests, lint, todo. Con Turborepo har\u00edas eso a mano o escribir\u00edas tus propios scripts. Cuando tienes un equipo que constantemente est\u00e1 creando nuevos paquetes o apps, la consistencia que esto compra es real.<\/p>\n
Here is the thing: Nx asume que vas a vivir en su ecosistema. Si adoptas los generators, la CLI, los executors, tienes un entorno muy cohesivo. Pero si quieres usar algo que Nx no soporta nativamente \u2014 un bundler ex\u00f3tico, un runner de tests menos popular \u2014 la experiencia se complica. Los plugins de la comunidad existen, pero la calidad var\u00eda bastante dependiendo de a qui\u00e9n le toque mantener ese plugin el a\u00f1o que viene.<\/p>\n
El Jueves que Nx Me Rompi\u00f3 el CI en Cuatro Pipelines Distintos<\/h2>\n
Aqu\u00ed viene la parte honesta.<\/p>\n
Estaba en la segunda semana de pruebas, habiendo migrado el proyecto a Nx. Todo iba bien en local. Hice push un jueves por la tarde \u2014 no un viernes<\/a>, lo juro, aprend\u00ed esa lecci\u00f3n en otro contexto \u2014 y los cuatro pipelines del repo fallaron todos al mismo tiempo con el mismo error:<\/p>\n
NX   The "inputs" for "build" in project.json of app-cliente are invalid.\n<\/code><\/pre>\n
El problema result\u00f3 ser una incompatibilidad entre c\u00f3mo Nx 20.2 interpreta los namedInputs<\/code> heredados desde nx.json<\/code> vs. los definidos localmente en el project.json<\/code> de cada app. Hab\u00eda un issue abierto en GitHub que describ\u00eda exactamente mi caso. La soluci\u00f3n era actualizar a 20.3 (que sali\u00f3 dos d\u00edas despu\u00e9s) o a\u00f1adir un override expl\u00edcito en cada project.json<\/code>.<\/p>\n
Eleg\u00ed el override porque no quer\u00eda actualizar en medio de la evaluaci\u00f3n y perder la comparabilidad de datos<\/a>. Eso signific\u00f3 tocar seis archivos distintos para arreglar algo que funcionaba perfectamente en la versi\u00f3n anterior.<\/p>\n
No fue catastr\u00f3fico. Pero me hizo pensar: con Turborepo, en dos semanas<\/a> de uso, no tuve ning\u00fan error parecido. La configuraci\u00f3n es m\u00e1s simple, hay menos lugares donde algo puede salir mal de formas sutiles. Uno de mis colegas \u2014 que lleva m\u00e1s tiempo con Nx que yo \u2014 me dijo que este tipo de cosas pasa menos a medida que te familiarizas con el sistema y aprendes qu\u00e9 no tocar. Puede ser. Pero “aprende qu\u00e9 no tocar” no es el tipo de conocimiento que quieres que tu equipo junior tenga que acumular de la manera dif\u00edcil.<\/p>\n
Lo que s\u00ed me sorprendi\u00f3 positivamente, en retrospectiva: el error fue descriptivo. Nx al menos me dijo exactamente qu\u00e9 proyecto fallaba y en qu\u00e9 campo. He visto errores de build mucho m\u00e1s oscuros en otras herramientas.<\/p>\n
Mi Recomendaci\u00f3n Seg\u00fan el Tama\u00f1o Real de<\/a> Tu Equipo<\/h2>\n
Despu\u00e9s de dos semanas<\/a>, una migraci\u00f3n, un bug de CI y bastantes horas leyendo docs, llegu\u00e9 a una lectura bastante clara.<\/p>\n
Equipos de menos de 10 personas con menos de 10 proyectos en el monorepo: Turborepo es suficiente y mucho menos overhead. El tiempo que ahorras en setup y mantenimiento es real. El cach\u00e9 local funciona excelente, y si ya est\u00e1s en Vercel, el Remote Cache es pr\u00e1cticamente gratis. El modelo mental es simple \u2014 puedes onboardear a alguien nuevo en una<\/a> tarde.<\/p>\n
La ecuaci\u00f3n cambia cuando el equipo crece. M\u00faltiples squads tocando el mismo repo, o m\u00e1s de 15-20 proyectos en vuelo, y Nx empieza a tener sentido. Los generators mantienen consistencia entre proyectos sin depender de que cada desarrollador recuerde copiar el boilerplate correcto. El grafo de dependencias deja de ser un nice-to-have.<\/p>\n
Hay un tercer factor que casi nadie menciona: el stack. Si todo tu repo es Next.js + TypeScript, ambas herramientas funcionan muy bien. Si tienes una mezcla de React, Go, Python scripts y herramientas diversas, Nx tiene m\u00e1s plugins oficiales y m\u00e1s soporte para casos heterog\u00e9neos. Turborepo es agn\u00f3stico, pero eso tambi\u00e9n significa que conectas m\u00e1s piezas t\u00fa mismo.<\/p>\n
No he podido validar completamente c\u00f3mo escala Nx m\u00e1s all\u00e1 de los 50 proyectos \u2014 nunca he operado a esa escala personalmente \u2014 pero la arquitectura claramente fue dise\u00f1ada pensando en ese tama\u00f1o.<\/p>\n
Mi recomendaci\u00f3n real, sin el “depende de tu caso” de rigor: empieza con Turborepo<\/strong>. Es m\u00e1s r\u00e1pido de adoptar, m\u00e1s f\u00e1cil de mantener para equipos de<\/a> hasta 15 personas, y el modelo mental te va a ahorrar problemas el 80% del tiempo. Si en seis meses tu repo crece hasta el punto donde sientes que necesitas generators, visualizaci\u00f3n de grafo y soporte multi-framework de verdad<\/a>, ese es el momento de evaluar Nx \u2014 no antes.<\/p>\n
Migrar de Turborepo a Nx no es trivial, pero tampoco es el apocalipsis. Lo que<\/a> s\u00ed es costoso es adoptar Nx antes de tiempo y pasar meses peleando con su complejidad cuando Turborepo habr\u00eda resuelto tu problema con la mitad del esfuerzo.<\/p>\n
Nx tiene m\u00e1s features. Turborepo tiene menos sorpresas. En 2026<\/a>, con proyectos que van a toda velocidad y equipos que no quieren leer 40 p\u00e1ginas de docs para configurar el CI, las sorpresas me salen m\u00e1s caras que los features.<\/p>\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
Llevo tres a\u00f1os peleando con monorepos.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[1],"tags":[],"class_list":["post-502","post","type-post","status-publish","format-standard","hentry","category-general"],"_links":{"self":[{"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/posts\/502","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/comments?post=502"}],"version-history":[{"count":11,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/posts\/502\/revisions"}],"predecessor-version":[{"id":767,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/posts\/502\/revisions\/767"}],"wp:attachment":[{"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/media?parent=502"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/categories?post=502"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/tags?post=502"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}