Git Submodule oder Composer? Unser Framework kann beides.
Seit über 20 Jahren ist unser eigenes Framework das Herzstück vieler unserer (Kunden-)Projekte. Bisher haben wir dieses als "git submodule" eingebunden. Neu wird auch die Installation per "composer install" unterstützt.
Der Fokus: Schnell, sicher und schlank
Im Unterschied zu anderen vergleichbaren Lösungen nehmen wir keine Rücksicht auf Abwärtskompatibilität:
- PHP-Version: Es wird stets die aktuelle PHP-Version unterstützt.
- Zero Dependencies: Es besteht keine Abhängigkeit zu externen Bibliotheken.
- Performance: Die Response soll so schnell wie möglich ausgeliefert werden.
Git Submodule oder Composer?
Bisher haben wir unser Framework als Git Submodule in Projekte eingebunden. In der Vergangenheit wuchs die Nachfrage anderer Entwickler, das Framework auch über Composer (und Packagist) verfügbar zu machen.
Was ist eigentlich ein Git Submodule?
Ein Git Submodule ist wie ein "Projekt im Projekt". Man bindet ein Repository fest in einen Unterordnet des Hauptprojektes ein. Dadurch können verschiedene Projekte gemeinsam entwickelt werden, ohne dass sie sich gegenseitig beeinflussen.
Der Aufstieg von Composer
Composer ist der Standard-Paketmanager für PHP. Er ermöglicht es Entwicklern, Abhängigkeiten zu verwalten und lädt die gewünschten Libraries in ein vendor-Verzeichnis. Dies vereinfacht die Installation und Aktualisierung von PHP-Bibliotheken und Frameworks.
Die Unterschiede im Überblick
| Merkmal | Git Submodule | Composer (Packagist) |
|---|---|---|
| Versions-Bindung | Fixiert auf einen spezifischen Commit-Hash. | Nutzt Version-Constraints (z.B. ^2.0). |
| Update-Logik | git submodule update (zieht den exakten Stand). | composer update (sucht nach dem neuesten kompatiblen Tag). |
| Transparenz | Source-Code befindet sich im Hauptverzeichnis des Submodules. | Source-Code liegt in der Regel in einem eigenen Verzeichnis unter dem vendor-Ordner. |
| Abhängigkeiten | Keine automatische Auflösung von Dritt-Libraries. | Automatische Installation aller benötigten Pakete. |
| Eingriffstiefe | Bugfixes können auch direkt im Submodule gefixt und committet werden. | Fokus auf reine Nutzung (Read-only Workflow im vendor). |
| Autonomie | Funktioniert ohne externe Tools (nur Git nötig). | Erfordert Composer als installierte Abhängigkeit. |
Die technische Knacknuss: Das Autoloading
Die grösste Herausforderung bei der Composer-Integration war unser Autoloader. Das Framework besitzt einen eigenen, Autoloader mit integriertem Caching. Der Standard-Autoloader von Composer bietet kein Out-of-the-box Caching, was bei einer hohen Anzahl an PHP-Klassen Einbussen in der Performance bringen kann. Unser Framework soll zudem ohne externe Abhängigkeiten wie Composer funktionieren.
Aus diesem Grund haben wir uns dafür entschieden, weiterhin den eigenen Autoloader zu verwenden, auch wenn das Framework per Composer eingebunden wird.
Ausblick: Modularität und Automatisierung
Unser Ziel ist es, das Framework noch modularer zu gestalten. Die nächste grosse Herausforderung ist die Synchronisation von Projektdaten (z.B. View-Klassen), die ausserhalb des vendor-Verzeichnisses liegen.
Folgende möglichen Lösungswege werde ich dazu nun weiter evaluieren:
- Composer: install scripts
- Git Submodules: git hooks
So soll sichergestellt werden, dass bei einem Framework-Update auch projektspezifische Dateien im Root-Verzeichnis automatisch auf dem neuesten Stand bleiben.
Fazit
Ob per Composer, Git Submodule oder ganz klassich manuell per Dateisystem: Das Framework soll sich dem Workflow anpassen und nicht umgekehrt.
Weiterführende Links
- Unser Framework bei GitHub: https://github.com/Actra-AG/yuf
- Unser Framework bei Packagist: https://packagist.org/packages/actra/yuf