There is no license information available for the latest version (8.0.51) of this package.

8.0.51 2026-01-28 09:17 UTC

README

Die Situation vor dem Monorepo (History)

  • Packages leben in einzelnen Repos
  • Bei Änderungen wird in Isolation an dem Package gearbeitet
  • Packages werden separat in neuen Versionen released
  • Der Release Prozess beinhaltet für jedes Package einen Upmerge und ein separates Tagging
  • Bei substantiellen Updates - wie zum Beispiel einem Symfony Upgrade - sind nicht nur der Core, sondern alle Packages betroffen

Was das Monorepo erreichen möchte

  • Einfache und schnelle Updates für Core und Packages
  • Garantierte Kompatibilität der Packages untereinander und mit dem Core
  • Der Einsatz von Code Quality Tools für alle Packages
  • Die Möglichkeit, in Projekten trotzdem nur die Packages zu installieren, die benötigt werden
  • Schmerzfreie Releases
  • Häufige Releases

Der Weg zum Monorepo

  • Alle bestehenden Packages wurden im Packagist abandoned und im GitLab als archiviert markiert
  • Es wurde ein Monorepo angelegt, welches alle Packages beinhaltet
  • Es wurde für jedes Package ein readonly Split angelegt
  • Die Splits wurden als neue Einträge im Packagist angelegt
  • Die stillgelegten Packages verweisen auf die neuen
  • Der Split läuft automatisch per GitLab CI

Die Struktur des Monorepos

composer.json: Das composer file im root Ordner wird generiert und beinhaltet alle Packages, die im Monorepo enthalten sind.

monorepo-builder.php: Die Konfiguration für das Monorepo Builder Tool

packages: Hier leben alle Bundles, die wir per Monorepo zur Verfügung stellen. Jedes Package hat einen eigenen Ordner, der die Struktur eines Composer Packages hat.

.gilab-ci.yml: In der GitLab CI Datei wird der Split Prozess konfiguriert. Hier wird das Monorepo Split Tool aufgerufen, um die einzelnen Packages zu splitten und in Packagist zu veröffentlichen.

Das Monorepo hat einen eigenen Branch für jede Core Version, für die die Packages veröffentlicht werden. Es kann also auch packages geben, die nur in der aktuellen Version zur Verfügung stehen, oder welche, die es nur noch für alte Versionen von Chameleon gibt.

Mit dem Monorepo arbeiten

Das Monorepo zu installieren ist nur notwendig, wenn man an einem der Packages darin arbeiten möchte. Der normale Weg, Packages zu installieren, bleibt, sie einzeln im Composer file anzugeben.

Um das Monorepo zu installieren, kann es im Projekt mit chameleon-system-private/monorepo und der zum Core passenden Version angegeben werden. Das Monorepo ersetzt alle anderen Bundles, die ebenfalls eingetragen sind, sodass es reicht, das Monorepo zusätzlich anzugeben. Man muss die anderen Dependencies nicht entfernen.

Bundles editieren

Um ein Bundle, welches Teil des Monorepos ist, zu bearbeiten, installiert man sich das Monorepo entweder in ein bestehendes Projekt (empfohlen), oder man clont sich das Repo separat.

Nachdem man Änderungen an dem Package der Wahl gemacht hat, kann ein neues Tag vergeben werden und GitLab CI wird automatisch den Split Prozess anstoßen, der das Package in Packagist veröffentlicht.

Bundle Dependencies editieren

Sollte ein Bundle eine neue Dependency benötigen, oder eine bestehende Dependency aktualisiert werden, kann dies im Composer file des Bundles gemacht werden. Danach muss das composer File im root aktualisiert werden. Dazu wurde beim installieren des Monorepos eine Dev-Dependency installiert: der Monorepo Builder. Dieser kann dann wie folgt aufgerufen werden:

vendor/bin/monorepo-builder merge

Dieser Befehl aktualisiert das composer file im root Ordner und fügt die neue Dependency hinzu.

Sollte es Konflikte durch die Änderungen im Composer file geben, wird der Befehl fehlschlagen und sehr verständlich erklären, was das Problem ist.

Neue Bundles hinzufügen

Um ein neues Bundle zum Monorepo hinzuzufügen, müssen die Schritte gegangen werden, die bereits für das Editieren beschrieben wurden. Darüberhinaus muss ein neues Repo im GitLab angelegt werden, in welches der Split Prozess das einzeln installierbare Bundle pusht. Danach muss das neue Bundle in der gitlab-ci.yml Datei hinzugefügt werden, damit es im Split Prozess berücksichtigt wird. Das Format hier sollte selbst erklärend sein.

Der Prozess im Packagist ist derselbe wie bisher.