Monorepo: no siempre es la mejor opción

El atractivo del monorepo

Todo el código en un repositorio. Cambios atómicos que tocan múltiples paquetes. Dependencias internas siempre sincronizadas. Reutilización de código trivial.

Suena elegante. Y para equipos que lo necesitan, lo es.

Por qué funciona para los grandes

Google tiene tooling interno desarrollado durante décadas. Miles de ingenieros han pulido sistemas de build, testing, y deploy específicamente para su escala.

Cuando Google dice que el monorepo funciona, habla de su monorepo con su tooling. No del mismo concepto aplicado con herramientas genéricas.

La realidad del tooling público

Turborepo, Nx, Lerna, pnpm workspaces. Las opciones son muchas y cada una tiene tradeoffs.

Configurar un monorepo funcional requiere esfuerzo significativo. El build incrementa en complejidad. El CI/CD necesita optimizaciones para no correr todo en cada commit.

Para un equipo pequeño, ese overhead puede superar los beneficios.

Cuándo el monorepo aporta valor

Múltiples aplicaciones que comparten código significativo. Un SDK interno, componentes de UI, lógica de negocio común. Si estás copiando código entre repos, el monorepo elimina esa duplicación.

Cambios frecuentes que cruzan fronteras de paquete. Si cada feature requiere modificar tres repos y coordinar releases, el monorepo simplifica el flujo.

Equipo que trabaja en todo el stack. Si las mismas personas tocan frontend, backend, y librerías compartidas, el monorepo reduce fricción.

Cuándo el monorepo añade complejidad sin valor

Proyectos independientes que casualmente pertenecen a la misma organización. Un blog y una aplicación de e-commerce no tienen por qué estar juntos.

Equipos separados con ciclos de release diferentes. El beneficio de cambios atómicos desaparece si los equipos no coordinan.

Proyectos con stacks técnicos muy diferentes. Un backend en Go y un frontend en TypeScript comparten poco. El monorepo no aporta reutilización.

El problema del testing

En un monorepo, un cambio en un paquete compartido puede afectar a todo lo que depende de él. Los sistemas de testing deben ser lo suficientemente inteligentes para detectar qué testear.

Sin ese tooling, cada cambio corre todos los tests. O peor, no corre los tests necesarios y los bugs llegan a producción.

La alternativa pragmática

Repos separados con paquetes publicados. Más ceremonia para actualizar dependencias compartidas, pero menos complejidad de tooling.

Para equipos pequeños, la fricción de mantener versiones puede ser menor que la fricción de configurar y mantener un monorepo.

La pregunta correcta

No es "¿debería usar monorepo?". Es "¿qué problemas tengo y el monorepo los resuelve mejor que las alternativas?".

Si la respuesta es sincera, muchos equipos descubrirían que sus problemas reales no son los que el monorepo soluciona.