Los monorepos volvieron con fuerza. Empresas como Google y Meta los usan desde hace décadas, pero el tooling moderno, Turborepo, Nx, pnpm workspaces, hizo accesible el enfoque para equipos más pequeños. La pregunta es: ¿debería ser accesible para tu equipo?

Depende de problemas reales que tengas ahora, no de problemas teóricos que podrías tener en el futuro.

Lo que los monorepos resuelven bien

Compartición de código sin fricción

Cuando tienes un design system, una librería de utils, tipos compartidos o configuraciones que múltiples proyectos usan, un monorepo elimina la danza de versiones: no necesitas publicar un paquete para que otro proyecto use el cambio. Es una importación directa.

// En cualquier paquete del monorepo
import { Button } from '@company/ui'
import { formatDate } from '@company/utils'
import type { User } from '@company/types'

Refactoring atómico

Cuando cambias la interfaz de una función compartida, actualizas todos los consumidores en el mismo commit. Sin breaking changes, sin versioning pain, sin proyectos desactualizados usando API vieja por meses.

CI/CD más inteligente con build incremental

Herramientas como Turborepo y Nx detectan qué paquetes fueron modificados y corren solo los tests/builds afectados. En monorepos grandes, esto transforma pipelines de 20 minutos en pipelines de 3 minutos.

# Turborepo: corre solo lo que cambió
turbo run build test --filter='...[HEAD^1]'

Lo que los monorepos no resuelven

Los monorepos no hacen mejor un código malo. Si tienes dos proyectos con arquitectura inconsistente, ponerlos en el mismo repositorio no los va a alinear, va a exponer los conflictos más rápido.

Los monorepos no reemplazan las convenciones del equipo. La compartición de código solo funciona si las convenciones también son compartidas. Sin eso, tienes acoplamiento sin alineamiento.

Cuándo NO usar monorepo

  • Tienes 1-2 proyectos sin código compartido
  • Los proyectos tienen ciclos de deploy completamente independientes y ninguna superposición de dominio
  • Tu equipo no tiene experiencia con el tooling, el costo de aprendizaje es real
  • Estás en una fase de producto donde la velocidad individual de cada proyecto es más importante que la consistencia entre ellos

Turborepo vs Nx: la decisión práctica

Turborepo

Mejor para: equipos que quieren setup rápido, principalmente JavaScript/TypeScript, con foco en builds y tasks incrementales. API simple, configuración mínima, integra bien con Vercel.

// turbo.json: configuración mínima funcional
{
  "pipeline": {
    "build": {
      "dependsOn": ["^build"],
      "outputs": [".next/**", "dist/**"]
    },
    "test": {
      "dependsOn": ["build"]
    },
    "dev": {
      "cache": false,
      "persistent": true
    }
  }
}

Nx

Mejor para: monorepos más grandes, polyglot (múltiples lenguajes), equipos que necesitan generación de código, visualización de dependencias y capacidades de plugin. Más poder, más configuración.

# Nx: genera un nuevo proyecto en el monorepo
nx generate @nx/react:application my-app

# Visualiza el grafo de dependencias
nx graph

Estructura de un monorepo bien organizado

my-monorepo/
├── apps/
│   ├── web/           # Next.js app
│   ├── mobile/        # React Native
│   └── api/           # Node.js backend
├── packages/
│   ├── ui/            # Design system compartido
│   ├── config/        # ESLint, TypeScript, etc.
│   ├── utils/         # Funciones utilitarias
│   └── types/         # Tipos compartidos
├── turbo.json
├── pnpm-workspace.yaml
└── package.json

La regla de oro: apps/ contiene cosas que deployas. packages/ contiene cosas que importas. Ningún paquete debe depender de un app, pero los apps pueden depender de cualquier paquete.

La decisión

Si tienes o estás por tener múltiples proyectos con código compartido, equipos que trabajan en más de un proyecto, y la necesidad de cambios atómicos entre proyectos, el monorepo probablemente vale la inversión.

Si nada de esto aplica, estás intercambiando simplicidad por complejidad sin ganancia proporcional. Polyrepo funciona bien para muchas organizaciones.

La trampa a evitar: adoptar monorepo porque "las grandes empresas lo usan" o porque parece más profesional. La decisión debe ser siempre sobre problemas reales que tienes hoy.