La conversación monorepo a menudo comienza en el lugar equivocado. Alguien pregunta si es mejor tener un repositorio o varios, como si fuera una decisión de organización de carpetas. No lo es. Es una decisión sobre cómo los equipos coordinan el trabajo, y el repositorio es solo la parte visible del mismo.
Con TypeScript, esta decisión adquiere un sabor específico y poderoso: la posibilidad de compartir tipos entre bibliotecas frontend, backend y internas dentro del mismo espacio. Este es el argumento que hace que los equipos serios miren a monorepo, y también el argumento que oculta los costos que solo descubres más tarde.
Este texto es para quienes deciden la arquitectura y la organización del equipo, y necesitan sopesar ambas partes antes de firmar.
El verdadero atractivo: el tipo de contrato en vivo
La ganancia más concreta de un monorepo con TypeScript es el tipo compartido entre los extremos del sistema. El backend define el formato de una respuesta, el frontend consume ese mismo formato y ambos apuntan a la misma definición.
Cuando el backend cambia el formato de los datos, el frontend deja de compilar inmediatamente. No hay una reunión de alineación, no hay un documento de contrato desactualizado, no hay un error clásico en el que la API cambió y nadie advirtió a la interfaz. El compilador se convierte en el mecanismo de coordinación entre equipos.
Esto resuelve una de las mayores fuentes de fricción en los sistemas distribuidos: la desconexión entre quienes producen los datos y quienes los consumen. En depósitos separados, el contrato se guarda en fideicomiso y documentación. En monorepo escrito, el contrato reside en el código y se verifica con cada confirmación. Cualquiera que quiera llevar esta garantía aún más lejos, desde el banco hasta la interfaz, vale la pena considerar la seguridad de tipos de extremo a extremo con tRPC, Drizzle y Prisma](/post/type-safety-ponta-a-ponta-trpc-drizzle-prisma).
¿Qué más ofrece monorepo?
Además de los tipos, hay ganancias de coordinación que vale la pena mencionar. Un cambio que cruza el frontend y el backend encaja en una única confirmación y una única revisión, en lugar de convertirse en un baile de solicitudes de extracción sincronizadas entre repositorios.
La estandarización también es más fácil. Una configuración de pelusa, una versión de TypeScript, un conjunto de reglas de formato que se aplican a todo. En lugar de que cada repositorio se ramifique en su propio dialecto, el equipo mantiene una cultura técnica única, lo que reduce el costo de moverse entre proyectos.
Y está la reutilización del código interno. Una biblioteca de componentes, un conjunto de funciones de utilidad, reglas de dominio que sirven a más de una aplicación. En monorepo, este es un paquete interno que todos consumen en la versión actual, sin el ritual de publicar y actualizar dependencias con cada cambio.
Las compensaciones que nadie muestra al principio
Ahora la otra mitad de la historia, por qué un monorepo bien hecho es poderoso y un monorepo mal hecho es un ancla.
El primer costo es la construcción. Cuando todo convive, se necesitan herramientas que comprendan qué ha cambiado y reconstruyan solo lo necesario; de lo contrario, cada pequeño cambio desencadena un proceso lento que crece con el repositorio. Sin un almacenamiento en caché inteligente y una compilación incremental, el tiempo de canalización se convierte en una queja diaria para el equipo.
El segundo costo es la gobernanza. Un repositorio donde cualquiera puede importar cualquier cosa desde cualquier lugar rápidamente degenera en una maraña de dependencias cruzadas. El frontend acaba importando algo que sólo tenía sentido en el backend, y la separación que existía en el papel desaparece en la práctica. Monorepo requiere límites explícitos y la disciplina para mantenerlos.
El tercer coste es menos técnico y más humano. Un repositorio único significa un único punto de coordinación. Permisos, propietarios de código, revisión, flujo de lanzamiento. Todo esto empieza a convivir en el mismo espacio y los equipos grandes necesitan reglas de propiedad claras para evitar pisarse unos a otros todo el tiempo.
Cuando realmente vale la pena
La decisión se vuelve más sencilla cuando se mira el perfil del problema en lugar de seguir las tendencias. Monorepo con TypeScript brilla cuando el frontend y el backend pertenecen al mismo equipo o a equipos muy cercanos y cambian juntos con frecuencia.
Brilla cuando hay un código de dominio genuinamente compartido entre aplicaciones, y el costo de mantenerlo sincronizado en repositorios separados ya está afectando. Brilla cuando el contrato entre capas cambia lo suficiente como para que la verificación automática de tipos pague la inversión de armar el marco.
Por otro lado, si los sistemas son verdaderamente independientes, evolucionan a ritmos diferentes y pertenecen a equipos que apenas se comunican entre sí, forzar un monorepo crea un acoplamiento donde no lo había. Se paga la complejidad sin cosechar la coordinación, porque no hubo coordinación para cobrar. En este caso, los repositorios separados con tipos publicados como un paquete versionado suelen ser mejores.
Qué considerar antes de adoptar
Antes de mover algo, vale la pena responder algunas preguntas honestamente, porque las respuestas determinan si Monorepo lo ayudará o lo obstaculizará.
El primero tiene que ver con la madurez de la herramienta. ¿Tiene, o está dispuesto a mantener, la infraestructura de almacenamiento en caché y compilación incremental que requiere un monorepo saludable? Sin esto, el tiempo de tramitación erosionará la ganancia de coordinación. Esta es una decisión de inversión continua, no una configuración única.
El segundo tiene que ver con la disciplina fronteriza. ¿Está el equipo dispuesto a definir y hacer cumplir los límites entre paquetes, incluso cuando cruzar la frontera parece más rápido en ese momento? Monorepo sin gobernanza se convierte en un código espagueti a mayor escala.
El tercero es sobre el problema que estás resolviendo. ¿Está adoptando monorepo porque la falta de tipos compartidos está provocando errores y fricciones reales, o porque se ha convertido en estándar y parece organizado? La primera razón justifica el costo. El segundo casi nunca.
La decisión es de organización, no de carpeta
Al final, el monorepo con TypeScript es una elección para alinear la forma en que trabajan los equipos, con el tipo compartido sirviendo como pegamento técnico entre ellos. Cuando los equipos realmente necesitan trabajar juntos, es una de las estructuras más efectivas que existen. Cuando no lo necesitan, la complejidad se disfraza de buena práctica.
El liderazgo técnico que decide bien es el que separa la ganancia real, que es la coordinación verificable por el compilador, de la estética de tener todo en un solo lugar. El primero justifica la inversión. La segunda es una trampa costosa.
Si está sopesando esta decisión, primero determine cómo sus equipos cambian el código juntos hoy y dónde está la fricción. La estructura del repositorio debe seguir la realidad del trabajo, nunca al revés. Para obtener una imagen completa de cómo los tipos sustentan un sistema completo, vale la pena comenzar con por qué TypeScript se convirtió en el estándar.
Lea también
- TypeScript avanzado en la práctica: lo que separa el uso superficial del uso maduro
- Por qué TypeScript se convirtió en el estándar en la Web moderna
- Validación de datos con Zod: por qué los tipos TypeScript no son suficientes
- Servidor primero: la decisión arquitectónica para quitarle peso al navegador
- Seguridad tipográfica de extremo a extremo: desde el banco hasta el frontend sin romper en las fronteras
- Microfrontends: cuándo y por qué adoptar en proyectos escalables