Software-Abhängigkeiten im Griff: Wie man Dependency-Hell bei Legacy-Projekten löst

Ein Entwickler will ein einzelnes Plugin aktualisieren. Danach startet die Anwendung nicht mehr. Eine andere Bibliothek braucht zwingend die alte Version, eine dritte zwingend die neue. Genau das nennt man Dependency Hell: Verschiedene Teile eines Projekts verlangen sich gegenseitig ausschließende Versionen von Abhängigkeiten, also von externen Programmbausteinen, auf die die eigene Software aufbaut.

Bei neuen Projekten kommt das selten vor. Bei Legacy-Software ist es fast schon der Normalzustand.

Wie Dependency Hell überhaupt entsteht

Jede moderne Anwendung nutzt fremden Code. PHP-Projekte laden Pakete über Composer, JavaScript-Projekte über npm. Das spart Zeit, denn niemand schreibt einen Login oder eine PDF-Erzeugung selbst neu.

Das Problem entsteht über die Jahre. Ein Paket wird 2015 eingebunden, funktioniert, und niemand fasst es mehr an. 2019 kommt ein zweites Paket dazu, das eine neuere Version derselben Bibliothek voraussetzt. 2023 ein drittes. Irgendwann verlangt jedes Paket etwas anderes von derselben Abhängigkeit, und die Versionsangaben widersprechen sich.

Dazu kommt: Manche Pakete werden nicht mehr gepflegt. Der Hersteller stellt die Weiterentwicklung ein, aktualisiert aber nie die Angabe, mit welchen neueren Versionen sein Code noch kompatibel ist. Das Paket blockiert dann jedes Update in seiner Umgebung, obwohl es technisch vielleicht sogar funktionieren würde.

Ein typischer Fall aus der Praxis: Ein Onlineshop nutzt eine Bibliothek für die PDF-Rechnung, die Version 2 einer Bildbearbeitungs-Bibliothek voraussetzt. Gleichzeitig braucht das Zahlungsmodul zwingend Version 4 derselben Bibliothek, weil ältere Versionen eine Sicherheitslücke enthalten, die der Zahlungsanbieter nicht mehr akzeptiert. Beide Anforderungen lassen sich in einem einzigen Projektstand nicht gleichzeitig erfüllen. Genau das ist der Kern des Problems: Zwei Anforderungen, die sich technisch ausschließen, treffen im selben Projekt aufeinander.

Composer und npm folgen dabei der sogenannten semantischen Versionierung. Eine Versionsnummer wie 4.2.1 sagt etwas über die Art der Änderung aus: Die erste Zahl kennzeichnet Änderungen, die bestehenden Code brechen können, die zweite neue Funktionen, die dritte kleine Korrekturen. Wenn ein Paket eine bestimmte erste Zahl fest vorschreibt, andere Pakete aber eine höhere verlangen, entsteht ein Widerspruch, den kein Tool automatisch auflösen kann.

Welche Konsequenzen das für Ihr Unternehmen hat

Ein solches Abhängigkeits-Chaos ist kein rein technisches Ärgernis. Es hat handfeste geschäftliche Folgen.

Sicherheitsupdates lassen sich nicht mehr einspielen, weil eine blockierende Abhängigkeit das verhindert. Damit bleiben bekannte Lücken offen, obwohl längst ein Patch existiert. Neue Funktionen lassen sich nicht mehr sauber einbauen, weil jede neue Bibliothek zusätzliche Konflikte mit sich bringt. Entwickler brauchen für einfache Änderungen plötzlich Tage statt Stunden, weil sie erst einen Weg durch das Geflecht widersprüchlicher Versionen finden müssen.

Am Ende landen viele Teams bei einer Notlösung: Sie frieren den gesamten Stand ein und rühren nichts mehr an. Das funktioniert eine Weile. Aber jede Woche ohne Updates ist eine Woche, in der sich weitere technische Schulden ansammeln, und aus einem lösbaren Problem wird ein größeres.

So diagnostizieren Sie das Ausmaß

Bevor irgendetwas repariert wird, muss klar sein, wie tief das Problem sitzt. Composer und npm liefern dafür eigene Werkzeuge.

Ein composer why-not zeigt, warum sich ein bestimmtes Paket nicht auf eine gewünschte Version anheben lässt. npm ls listet die komplette Abhängigkeitsstruktur inklusive doppelter oder widersprüchlicher Einträge auf. Beide Befehle machen sichtbar, welche Pakete die eigentlichen Blockierer sind.

Häufig zeigt sich dabei ein überschaubarer Kern des Problems: zwei oder drei veraltete Pakete, die den Rest des Systems festhalten. Das ist eine gute Nachricht. Es bedeutet, dass sich die Arbeit gezielt auf wenige Stellen konzentrieren lässt statt auf das gesamte Projekt.

Handlungsoptionen: Wie man aus der Sackgasse kommt

Es gibt keinen einzelnen Trick, der das Problem auflöst. Aber es gibt einen strukturierten Weg dorthin.

Zuerst werden die blockierenden Pakete einzeln geprüft. Wird das Paket noch gepflegt? Gibt es eine neuere, kompatible Version? Manchmal reicht schon ein einzelnes gezieltes Update, um mehrere Konflikte gleichzeitig zu lösen.

Wird ein Paket nicht mehr gepflegt, bleiben meist drei Wege. Man ersetzt es durch eine aktiv gepflegte Alternative mit ähnlicher Funktion. Man forkt den Code, also erstellt eine eigene Kopie, und pflegt die nötigen Anpassungen selbst weiter. Oder man schreibt die betroffene Funktion neu, wenn sie klein genug ist, um den Aufwand zu rechtfertigen.

Wichtig ist die Reihenfolge: ein Paket nach dem anderen, mit Tests nach jedem Schritt. Wer versucht, alle Konflikte auf einmal aufzulösen, verliert schnell den Überblick, welche Änderung welchen neuen Fehler ausgelöst hat.

Für PHP-Projekte lohnt sich außerdem ein Blick darauf, ob überhaupt eine saubere Versionsverwaltung über Composer existiert. Viele ältere Projekte haben Abhängigkeiten ursprünglich von Hand eingefügt, ganz ohne Versionsverwaltung. Das macht die Diagnose zusätzlich schwerer, lässt sich aber nachrüsten.

Wie man das künftig vermeidet

Ist das akute Problem gelöst, folgt die eigentlich wichtigere Frage: Wie verhindert man, dass es sich wiederholt?

Regelmäßige, kleine Updates schlagen große, seltene Sprünge. Wer alle paar Wochen ein Paket aktualisiert, merkt Konflikte sofort und kann sie klein lösen. Wer drei Jahre wartet, steht am Ende vor genau dem Problem, das dieser Artikel beschreibt. Wie man das in der Praxis organisiert, zeigt unser Artikel dazu, wie man Abhängigkeiten aktuell hält.

Für JavaScript-Projekte kommt ein zweiter Aspekt hinzu: Veraltete npm-Pakete sind nicht nur ein Kompatibilitätsrisiko, sondern auch ein Sicherheitsrisiko. Bekannte Lücken in verbreiteten Paketen werden gezielt für Angriffe genutzt. Was dabei konkret droht, beschreiben wir im Artikel über npm-Pakete und ihre Sicherheitsrisiken.

Am Ende ist dieses Abhängigkeits-Chaos eine Form von technischen Schulden: Jede aufgeschobene Aktualisierung ist ein kleiner Kredit auf die Zukunft, und die Zinsen laufen weiter, solange niemand tilgt.

Wer intern kein Team hat, das solche Konflikte regelmäßig auflöst, gerät fast zwangsläufig irgendwann in dieselbe Lage. Nicht aus Nachlässigkeit, sondern weil das Tagesgeschäft meist wichtiger erscheint als eine Versionsnummer, die gerade noch funktioniert. Genau deshalb lohnt sich ein fester Rhythmus für Updates mehr als ein gelegentlicher Kraftakt.

Fazit: Ein lösbares Problem, wenn man es strukturiert angeht

Dependency Hell fühlt sich oft größer an, als es tatsächlich ist. Mit einer sauberen Diagnose, einem Paket nach dem anderen und ausreichend Tests lässt sich das Geflecht Stück für Stück entwirren. Der Aufwand hängt vom Alter und der Größe des Projekts ab, ist aber fast immer geringer als ein kompletter Neuaufbau.

Wenn Ihre Anwendung sich nicht mehr sauber aktualisieren lässt, sollten Sie nicht länger abwarten. Sprechen Sie uns an. Das Erstgespräch ist kostenlos. Wir schauen uns Ihre Abhängigkeiten an und sagen Ihnen ehrlich, wie viel Arbeit tatsächlich dahintersteckt.