Todo sobre el Monorepo

¿Qué es un Monorepo?

• "Varios proyectos individuales contenidos en un solo repo mediante relaciones bien definidas"
• Monorepo ≠ Monolith

¿Por qué hacerlo?

• La razón para elegir el modelo Polyrepo tradicional (usar varios repos) era la "autonomía de los equipos (team autonomy)"
  • Los equipos pueden elegir las librerías que quieran y decidir quién contribuye al código y quién lo usa
• PolyRepo
  • Compartir código es engorroso
  • Hay mucha duplicación de código
  • Corregir bugs críticos o hacer cambios grandes en librerías compartidas cuesta mucho
  • Uso inconsistente de herramientas de desarrollo entre proyectos
• Monorepo
  • No hay sobrecarga al crear nuevos proyectos
  • Commits atómicos en todo el conjunto de proyectos
  • Todo se gestiona con un solo número de versión
  • Movilidad de desarrolladores (entre proyectos)

Funciones que ofrecen las herramientas de Monorepo y comparación entre ellas

→ Bazel, Gradle, Lage, Lerna, Nx, Rush, Turborepo

• Caché local
• Orquestación local de tareas
• Caché distribuido
• Ejecución distribuida de tareas
• Ejecución remota transparente
• Detección de proyectos/paquetes afectados
• Análisis del workspace
• Visualización del grafo de dependencias
• Compartir código
• Tooling consistente
• Generación de código
• Restricciones y visibilidad de proyectos

Cambio de perspectiva

Los monorepos cambian la forma en que piensas sobre tu "organización y tu código"

• Añadiendo consistencia,
• reduciendo la fricción al crear nuevos proyectos o realizar grandes refactorizaciones,
• fomentando el intercambio de código y la colaboración entre equipos,
• la organización puede trabajar de forma más eficiente

Hay varias soluciones, pero cada una tiene objetivos distintos

• Bazel (by Google) : “A fast, scalable, multi-language and extensible build system.”
• Gradle (by Gradle, Inc) : “A fast, flexible polyglot build system designed for multi-project builds.”
• Lage (by Microsoft) : “Task runner in JS monorepos”
• Lerna : “A tool for managing JavaScript projects with multiple packages.”
• Nx (by Nrwl) : “Next generation build system with first class monorepo support and powerful integrations.”
• Rush (by Microsoft) : “Geared for large monorepos with lots of teams and projects. Part of the Rush Stack family of projects.”
• Turborepo (by Vercel) : “The high-performance build system for JavaScript & TypeScript codebases.”

[kleinstein]

Cuando desarrollas una aplicación y la instalas para cada cliente, hay clientes que en algún momento ya no quieren más actualizaciones, y también hay clientes que piden una versión especial solo para ellos.

Entonces, a medida que este tipo de clientes empieza a aumentar, al final el repositorio termina lleno de decenas de ramas con versiones personalizadas para cada cliente. En cada rama hay una versión un poco distinta.

Al ver un artículo sobre Monorepo en una situación así... realmente suena como un sueño. jaja

[bbulbum]

Me acordé de cuando Torvalds dijo que, en la mayoría de los casos, las bibliotecas compartidas no son una buena idea... Lo estuve probando recientemente y, la verdad, hay menos partes que realmente valga la pena compartir de lo que esperaba, mientras que los problemas de que el sistema de build se enrede son grandes, así que yo siento que el monorepo no es un sistema tan ideal como prometía.

[galadbran]

En la época en que subversion era la norma, esto simplemente era algo demasiado obvio, así que me parece bastante irónico.
También me resulta extraño que se trate solo limitado al desarrollo frontend.
En MS incluso crearon un sistema de archivos virtual para poder usar git como subversion, pero me da pena que eso no se haya generalizado.

[xguru]

Siento que últimamente esa sensación de que la tecnología va y vuelve se ha vuelto más fuerte.
A veces pienso: “Oye, ¿esto no es aquello que antes no estaba tan bueno?”, así que me pregunto si ya llevo demasiado tiempo en esto. Snif, snif.