PHP Composer: Warum Dependency-Management bei alten Projekten fehlt – und was das bedeutet

Viele PHP-Legacy-Projekte haben kein Dependency-Management. Composer, das heute übliche Werkzeug dafür, gibt es erst seit 2012. Wer vorher gebaut hat, hat Abhängigkeiten anders verwaltet: manuell, per Hand, ohne Versionskontrolle. Das hat damals funktioniert. Heute erzeugt es Probleme, die sich häufen.

Dieser Artikel erklärt, was Composer ist, warum er in älteren PHP-Projekten oft fehlt und was das konkret bedeutet. Für die Sicherheit. Für die Wartung. Für die Kosten.

Was ist PHP Composer?

Composer ist ein Werkzeug zur Verwaltung externer Bibliotheken in PHP-Projekten. Bibliotheken, also Code von Drittanbietern, sind Bausteine die eine Anwendung nutzt. Eine Bibliothek zum Versenden von E-Mails. Eine andere zum Erstellen von PDFs. Eine für die Datenbankverbindung.

Composer übernimmt drei Aufgaben. Er lädt diese Bibliotheken in der richtigen Version herunter. Er löst auf, wenn eine Bibliothek selbst weitere Bibliotheken benötigt. Und er dokumentiert exakt, was installiert ist, in welcher Version.

Das Ergebnis ist ein reproduzierbares System. Auf dem lokalen Rechner, auf dem Testserver und in der Produktion läuft dieselbe Version jeder Abhängigkeit. Keine Überraschungen.

PHP Composer in Legacy-Projekten fehlt aus einem einfachen Grund: Er existierte nicht, als viele dieser Systeme gebaut wurden.

Wie wurden Abhängigkeiten früher verwaltet?

Vor Composer gab es keinen Standard. Jedes Team hat das auf eigene Weise gelöst.

Die häufigste Variante war der manuelle Download. Eine Bibliothek wurde von der Hersteller-Website heruntergeladen, in einen Ordner gelegt und per require eingebunden. Das war schnell erledigt.

Das Problem: Diese Methode hinterlässt keine Spur. Es gibt keine Aufzeichnung, welche Version eingebunden wurde. Keinen Zeitstempel. Keine Quelle. Wenn drei Jahre später ein anderer Entwickler die Datei durch eine neuere Version ersetzt, weiß niemand, was sich geändert hat.

Noch problematischer: Manche Teams haben externe Bibliotheken direkt verändert. Nötige Anpassungen wurden im Code der Fremdbibliothek vorgenommen, nicht in einem separaten Modul. Das macht jedes spätere Update unmöglich. Die eigenen Änderungen würden beim Einspielen einer neuen Version überschrieben.

Das ist ein typisches Beispiel für technische Schulden: eine Entscheidung, die schnell war und damals sinnvoll schien, aber langfristig Kosten erzeugt.

Welche Risiken entstehen durch fehlenden Composer?

Sicherheitslücken bleiben unbekannt und offen

Das ist das konkreteste Risiko. Eine Bibliothek, die 2009 manuell eingebunden wurde und seitdem nicht mehr aktualisiert wurde, hat sehr wahrscheinlich bekannte Sicherheitslücken.

Solche Lücken werden in öffentlichen Datenbanken dokumentiert. Ein CVE (Common Vulnerabilities and Exposures) ist ein solcher Eintrag. Er beschreibt die Lücke, nennt betroffene Versionen und enthält oft Hinweise zur Ausnutzung.

Wer die Versionsnummer einer eingebundenen Bibliothek nicht kennt, kann nicht prüfen, ob sie betroffen ist. Und wer nicht prüfen kann, kann nicht reagieren.

Mit Composer gibt es ein Werkzeug, das automatisch prüft, ob eine verwendete Version bekannte Schwachstellen hat. Ohne Composer gibt es das nicht.

Updates werden zu Projekten statt zu Routineaufgaben

Mit Composer ist ein Bibliotheks-Update ein einziger Befehl. Ohne Composer ist es eine Recherche-Aufgabe.

Zuerst muss man herausfinden, welche Bibliotheken überhaupt im Einsatz sind. Dann die jeweilige aktuelle Version finden. Dann herunterladen, einbauen, testen. Und das für jede Abhängigkeit einzeln.

Weil das aufwändig ist, wird es aufgeschoben. Weil es aufgeschoben wird, wächst der Abstand zwischen Updates. Das macht das nächste Update noch aufwändiger. Ein Kreislauf, der sich irgendwann selbst blockiert.

Das Ergebnis: Systeme, bei denen Bibliotheken seit fünf oder zehn Jahren nicht mehr aktualisiert wurden. Nicht weil jemand es vergessen hat, sondern weil der Aufwand zu hoch erschien.

Keine Reproduzierbarkeit der Umgebung

Composer erzeugt eine composer.lock-Datei. Sie hält fest, welche Version jeder Bibliothek installiert ist. Das stellt sicher, dass auf jedem Rechner und in jeder Umgebung dieselbe Software läuft.

Ohne diese Datei gibt es diese Garantie nicht. Was lokal funktioniert, muss auf dem Server nicht funktionieren. Was gestern lief, muss heute nicht mehr laufen, wenn jemand eine Bibliothek ausgetauscht hat.

Das erschwert die Fehlersuche erheblich. Probleme, die sich nicht reproduzieren lassen, kosten besonders viel Zeit.

Composer nachträglich einführen: ist das möglich?

Ja. Es ist kein einfacher, aber ein machbarer Weg.

Der erste Schritt ist eine Bestandsaufnahme. Welche externen Bibliotheken sind im Projekt vorhanden? In welcher Version? Gibt es sie noch auf Packagist, dem offiziellen PHP-Paketverzeichnis? Falls ja, lassen sie sich in eine Composer-Konfiguration überführen.

Der zweite Schritt ist das Einrichten von Composer und das schrittweise Ersetzen der manuellen Einbindungen durch Composer-verwaltete Pakete.

Besonders aufwändig wird das, wenn Bibliotheken direkt verändert wurden. Dann müssen diese Änderungen zuerst identifiziert, dokumentiert und in einem separaten Paket abgebildet werden.

Das lohnt sich trotzdem. Ein System mit Composer ist langfristig günstiger zu betreiben als eines ohne. Updates werden zumutbar. Sicherheitslücken lassen sich gezielt adressieren. Neue Mitarbeiter können sich schneller einarbeiten.

Das Einführen von Composer ist oft ein früher Schritt in der Software-Wartung. Es vereinfacht alles, was danach kommt.

Was man ohne Composer sofort tun kann

Wer nicht sofort ein vollständiges Composer-Einführungsprojekt anstoßen kann, sollte zumindest eine Inventarliste anlegen. Welche externen Bibliotheken sind vorhanden? Welche Version? Wo wurde sie heruntergeladen?

Das ist kein Ersatz für Composer. Aber es ist der erste Schritt aus dem Dunkel. Wer weiß was er hat, kann zumindest manuell prüfen, ob bekannte Lücken vorliegen.

Der nächste Schritt ist immer Composer. Nicht irgendwann, sondern beim nächsten Wartungsfenster.

Fazit

PHP-Projekte ohne Composer sind kein Randphänomen. Ein großer Teil der aktiv laufenden PHP-Anwendungen wurde in einer Zeit gebaut, als es Composer noch nicht gab. Das ist kein Versäumnis der damaligen Entwickler. Es ist ein Hinweis auf das, was heute Handlungsbedarf erzeugt.

Unbekannte Bibliotheksversionen, offene Sicherheitslücken, nicht reproduzierbare Umgebungen: Das sind die konkreten Folgen. Sie lassen sich beheben.

Sprechen Sie uns an. Wir schauen uns Ihr System an und sagen Ihnen ehrlich, was sich angesammelt hat und wie man es strukturiert angeht. Das Erstgespräch ist kostenlos.