1 
2Cuando se trabaja en proyectos de software complejos, la elección entre monorepo y polyrepo puede tener un impacto significativo en la productividad del equipo y la escalabilidad del código. En este artículo analizamos las diferencias, los pros y los contras de cada enfoque, y te ayudamos a entender cuál es el más adecuado para ti.
3 
4## ¿Qué son Monorepo y Polyrepo?
5 
6### Monorepo
7 
8Un **monorepo** (monolithic repository) es un único repositorio que contiene el código fuente de varios proyectos, servicios o paquetes, a menudo relacionados entre sí.
9 
10```plaintext filename="Ejemplo de estructura Monorepo"
11my-monorepo/
12  packages/
13    frontend/
14    backend/
15    shared/
16  package.json
17  turbo.json
18```
19 
20### Polyrepo
21 
22Un **polyrepo** (multiple repositories) implica que cada proyecto, servicio o paquete tiene su propio repositorio separado.
23 
24```plaintext filename="Ejemplo de estructura Polyrepo"
25repos/
26  frontend/
27    package.json
28  backend/
29    package.json
30  shared/
31    package.json
32```
33 
34## Diferencia visual
35 
36```mermaid
37flowchart TD
38    subgraph Monorepo
39        A1["frontend/"]
40        A2["backend/"]
41        A3["shared/"]
42    end
43    style Monorepo fill:#e0e7ff,stroke:#6366f1,stroke-width:2px
44```
45 
46```mermaid
47flowchart TD
48    subgraph Polyrepo
49        B1["frontend repo"]
50        B2["backend repo"]
51        B3["shared repo"]
52    end
53    style Polyrepo fill:#fee2e2,stroke:#ef4444,stroke-width:2px
54```
55 
56## Pros y contras
57 
58### Monorepo
59 
60**Ventajas:**
61- Facilita el intercambio de código (por ejemplo, bibliotecas compartidas).
62- Refactorización atómica en varios proyectos.
63- Gestión centralizada de dependencias y configuraciones.
64 
65**Desventajas:**
66- Puede volverse pesado a medida que crece el código.
67- Requiere herramientas para gestionar builds/tests parciales (por ejemplo, Nx, Turborepo).
68 
69### Polyrepo
70 
71**Ventajas:**
72- Cada equipo/proyecto es independiente.
73- Más fácil de gestionar para proyectos pequeños.
74- Permite políticas de acceso granulares.
75 
76**Desventajas:**
77- Difícil compartir código sin publicar paquetes.
78- Refactorización entre repositorios más compleja.
79- Posible duplicación de configuraciones.
80 
81## Ejemplo práctico: Monorepo con Turborepo
82 
83Supongamos que quieres crear un monorepo con frontend y backend usando Turborepo.
84 
85### 1. Inicializa el monorepo
86 
87```bash
88npx create-turbo@latest
89```
90 
91### 2. Estructura típica
92 
93```plaintext
94my-monorepo/
95  apps/
96    web/        # frontend Next.js
97    api/        # backend Node.js/Express
98  packages/
99    ui/         # biblioteca de componentes compartidos
100    utils/      # funciones compartidas
101  turbo.json
102  package.json
103```
104 
105### 3. Ejemplo de workspace en `package.json`
106 
107```json
108{
109  "private": true,
110  "workspaces": [
111    "apps/*",
112    "packages/*"
113  ]
114}
115```
116 
117### 4. Ejemplo de importación de una biblioteca compartida
118 
119Supongamos que tienes una función en `packages/utils/src/formatDate.ts`:
120 
121```ts
122// packages/utils/src/formatDate.ts
123export function formatDate(date: Date): string {
124  return date.toLocaleDateString('es-ES');
125}
126```
127 
128En el frontend:
129 
130```ts
131// apps/web/pages/index.tsx
132import { formatDate } from '@myorg/utils';
133 
134export default function Home() {
135  return <div>Hoy es {formatDate(new Date())}</div>;
136}
137```
138 
139## ¿Cuándo elegir Monorepo?
140 
141- Equipos medianos o grandes que trabajan en varios proyectos relacionados.
142- Necesidad de compartir código y realizar refactorizaciones a gran escala.
143- Proyectos que crecen rápidamente y requieren builds/tests optimizados.
144 
145## ¿Cuándo elegir Polyrepo?
146 
147- Proyectos pequeños o independientes.
148- Equipos separados que trabajan en productos diferentes.
149- Políticas de acceso muy restrictivas.
150 
151## Conclusión
152 
153No existe una solución perfecta para todos. La elección depende del tamaño del equipo, la complejidad de los proyectos y las necesidades de colaboración. Lo importante es ser consciente de los trade-offs y elegir las herramientas adecuadas para gestionar la complejidad.