Alles über Monorepos

Was ist ein Monorepo

• „Mehrere einzelne Projekte in einem Repo zusammenzufassen, verbunden durch klar definierte Beziehungen“
• Monorepo ≠ Monolith

Warum sollte man das machen?

• Der Grund, sich bisher für Polyrepo zu entscheiden (die Nutzung mehrerer Repos), war die „Teamautonomie“
  • Teams konnten jeweils die Bibliotheken ihrer Wahl einsetzen und entscheiden, wer zum Code beiträgt und ihn nutzt
• PolyRepo
  • Code-Sharing ist umständlich
  • viel Codeduplizierung
  • kritische Bugs und große Änderungen an geteilten Bibliotheken verursachen hohe Kosten
  • inkonsistente Nutzung von Entwicklungstools je nach Projekt
• Monorepo
  • kein Overhead beim Anlegen neuer Projekte
  • atomische Commits über das gesamte Projekt hinweg
  • alles wird über eine einzige Versionsnummer verwaltet
  • Entwickler-Mobilität (Wechsel zwischen Projekten)

Welche Funktionen Monorepo-Tools bieten und Vergleich der einzelnen Werkzeuge

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

• lokales Caching
• lokale Task-Orchestrierung
• verteiltes Caching
• verteilte Task-Ausführung
• transparente Remote-Ausführung
• Erkennung betroffener Projekte/Packages
• Workspace-Analyse
• Visualisierung des Abhängigkeitsgraphen
• Code-Sharing
• konsistentes Tooling
• Codegenerierung
• Projekteinschränkungen und Sichtbarkeit

Ein Perspektivwechsel

Monorepos verändern eure „Organisation und die Art, wie ihr über Code denkt“

• indem sie Konsistenz schaffen,
• Reibung beim Erstellen neuer Projekte oder bei groß angelegten Refactorings verringern,
• Code-Sharing und teamübergreifende Zusammenarbeit fördern
• und so Organisationen effizienter arbeiten lassen

Es gibt viele verschiedene Lösungen, aber jede verfolgt andere Ziele

• 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]

Wenn man Anwendungen entwickelt und sie bei jedem Kunden installiert,
kommt es vor, dass manche Kunden keine weiteren Upgrades mehr möchten,
während andere eine ganz eigene Sonderversion verlangen.

Wenn solche Kunden dann immer mehr werden,
ist das Repository am Ende mit Dutzenden kundenspezifischen Branches gefüllt.
In jedem Branch steckt eine leicht andere Version.

Wenn ich in so einer Situation etwas über Monorepos lese ... klingt das wirklich wie eine Traumgeschichte. haha

[bbulbum]

Ich muss daran denken, dass Torvalds gesagt hat, gemeinsam genutzte Bibliotheken seien in den meisten Situationen keine gute Idee. Ich probiere das in letzter Zeit aus, aber es gibt weniger gemeinsam nutzbare Teile als gedacht, und die Probleme, bei denen sich das Build-System verheddert, sind groß. Deshalb denke ich, dass ein Monorepo kein so ideales System ist, wie man erwartet hatte..

[galadbran]

In der Zeit, als Subversion der Standard war, war das einfach völlig selbstverständlich, deshalb finde ich es in vieler Hinsicht irgendwie ironisch.
Ich finde es auch merkwürdig, dass das Thema nur auf Frontend-Entwicklung beschränkt behandelt wird.
Microsoft hat ein virtuelles Dateisystem entwickelt, damit sich Git auch wie Subversion nutzen lässt, aber es ist schade, dass sich das nicht allgemein durchgesetzt hat.

[xguru]

Irgendwie hat man in letzter Zeit noch stärker das Gefühl, dass sich Technik ständig im Kreis dreht.
Manchmal denke ich dann: Hä, ist das nicht genau das Ding von früher, das schon damals nicht so toll war? .. Vielleicht bin ich einfach schon zu lange dabei. schnief