Composer-Abhaengigkeitsgraph in PhpStorm visualisieren

1. Warum der Composer-Graph in Magento-Projekten relevant ist

Ein typisches Magento-2-Projekt bindet neben dem Core-Paket magento/product-community-edition schnell 20 bis 50 Drittanbieter-Erweiterungen ein: Zahlungsanbieter, ERP-Konnektoren, SEO-Tools, PDF-Generatoren. Jedes dieser Pakete bringt eigene Anforderungen an symfony/*-Komponenten, guzzlehttp/guzzle, monolog/monolog oder psr/log mit. Composer loest diese Anforderungen automatisch auf, aber die resultierende composer.lock ist oft ein Kompromiss aus vielen einzelnen Zwaengen, den niemand im Team wirklich ueberblickt.

Genau hier hilft ein visueller Abhaengigkeitsgraph. Statt composer why-not oder composer depends paketweise abzufragen, zeigt PhpStorm den kompletten Baum als Diagramm: Wurzelpaket, direkte Abhaengigkeiten, transitive Abhaengigkeiten und die konkreten Versionsconstraints an jeder Kante. Das macht sichtbar, welches Paket beispielsweise eine veraltete guzzlehttp-Version erzwingt und damit ein geplantes Upgrade blockiert, ohne dass man das erst durch eine fehlgeschlagene composer update-Ausgabe erraten muss.

2. composer.json als PhpStorm-Projektstruktur verstehen

PhpStorm erkennt composer.json und composer.lock automatisch, sobald sie im Projekt-Root liegen, und bietet Autovervollstaendigung fuer Paketnamen und Versionsconstraints direkt beim Editieren. Voraussetzung ist, dass unter Settings > PHP > Composer der richtige Composer-Executable-Pfad hinterlegt ist, im Docker-Setup meist ueber ein Remote-Interpreter-Mapping oder den lokalen bin/composer-Wrapper von Mark Shust.

Ist die Composer-Integration aktiv, indiziert PhpStorm auch die installierten Pakete unter vendor/ und macht ihre Klassen fuer Navigation und Autovervollstaendigung nutzbar. Das ist die Voraussetzung fuer die Graph-Funktionalitaet, denn PhpStorm liest die Metadaten direkt aus composer.lock statt aus einer separaten Konfiguration. Ein composer install nach dem Auschecken eines Branches sorgt dafuer, dass der Graph immer den tatsaechlichen, aufgeloesten Zustand zeigt und nicht nur die abstrakten Constraints aus composer.json.

{
    "require": {
        "php": "~8.4.0",
        "magento/product-community-edition": "2.4.8-p4",
        "vendor-x/payment-connector": "^3.2",
        "vendor-y/erp-sync": "^1.9"
    }
}

3. Den Abhaengigkeitsgraph oeffnen und lesen

In aktuellen PhpStorm-Versionen findest du den Composer-Abhaengigkeitsgraph, indem du composer.json im Projektbaum mit der rechten Maustaste anklickst und im Kontextmenue den Punkt fuer die Dependency-Diagram-Ansicht waehlst. Alternativ laesst sich die Aktion ueber Find Action mit dem Suchbegriff 'Diagram' erreichen. PhpStorm baut daraufhin einen interaktiven Graphen auf, in dem jeder Knoten ein Paket ist und jede Kante eine Versionsanforderung traegt.

Wichtig ist die Leserichtung: Eine Kante von Paket A zu Paket B bedeutet, A verlangt B in einer bestimmten Version. Bei Magento-Projekten siehst du so zum Beispiel, dass magento/module-payment eine bestimmte Range von paypal/rest-api-sdk-php voraussetzt, waehrend ein separat eingebundenes Drittanbieter-Modul eine inkompatible Range derselben Bibliothek verlangt. Der Graph macht diesen Widerspruch sofort sichtbar, waehrend composer update ihn nur als kryptische Fehlermeldung ausgibt.

4. Versionskonflikte am Graphen erkennen

Ein Versionskonflikt zeigt sich im Graphen meist dadurch, dass zwei Kanten auf denselben Knoten zeigen, aber mit sich ausschliessenden Constraints beschriftet sind, etwa ^6.0 und ^7.0 fuer guzzlehttp/guzzle. PhpStorm loest diese Faelle nicht automatisch auf, aber es macht die betroffenen Knoten optisch greifbar, sodass du gezielt nachschauen kannst, welches der beiden Pakete eine neuere oder eine grosszuegigere Versionsangabe erlauben wuerde.

In der Praxis hilft die Kombination aus Graph und Terminal: Den Konfliktknoten im Graphen identifizieren, dann gezielt composer why-not vendor-y/erp-sync guzzlehttp/guzzle:^7.0 im bin/composer-Wrapper ausfuehren, um die exakte Kette zu bestaetigen, die die aeltere Version erzwingt. So bleibt der Graph das schnelle Orientierungsmittel, waehrend die CLI die Details liefert, die fuer eine fundierte Entscheidung noetig sind.

# Im Terminal, nachdem der Graph einen verdaechtigen Knoten zeigt
bin/composer why-not guzzlehttp/guzzle 7.9

# Ausgabe zeigt die genaue Kette, z.B.:
# vendor-y/erp-sync 1.9.2 requires guzzlehttp/guzzle (^6.5)

5. Tiefe Abhaengigkeitsketten vor einem Upgrade verstehen

Nicht jeder Konflikt ist ein direkter Widerspruch, viele Probleme entstehen erst drei oder vier Ebenen tief im Graphen. Ein Zahlungsmodul haengt von einem SDK ab, das SDK haengt von einer aelteren symfony/http-client-Version ab, und diese wiederum verlangt eine PHP-Version, die mit dem geplanten PHP-8.4-Upgrade kollidiert. Solche Ketten sind in einer flachen composer.json-Ansicht praktisch unsichtbar.

Der Graph erlaubt es, node-weise zu expandieren und gezielt in die Tiefe zu navigieren, statt die komplette composer.lock durchzulesen. Bei einem geplanten Magento-Upgrade lohnt es sich, gezielt die Kernpakete magento/framework und magento/module-* als Ausgangspunkt zu waehlen und von dort aus zu pruefen, welche Drittanbieter-Module ueber mehrere Ebenen an veralteten Bibliotheken haengen. Das reduziert die Upgrade-Vorbereitung von geratenem Ausprobieren auf gezielte Recherche.

6. Besonderheiten bei Magento-Composer-Metapaketen

Magento nutzt selbst ein mehrstufiges Metapaket-System: magento/product-community-edition zieht magento/magento2-base, das wiederum dutzende magento/module-*-Pakete referenziert. Im Graphen erscheinen diese Metapakete als Knoten mit sehr vielen ausgehenden Kanten, was den Graphen schnell unuebersichtlich macht, wenn man ihn ungefiltert vom Wurzelpaket aus betrachtet.

Praktikabler ist es, den Graphen nicht vom Root aus, sondern gezielt von einem einzelnen Drittanbieter-Paket aus zu betrachten und dessen Abhaengigkeiten zu verfolgen. So blendest du den riesigen Magento-Kern-Teilbaum aus und siehst nur die fuer den aktuellen Konflikt relevanten Knoten. Bei Composer-Plugin-Paketen wie hyva-themes/magento2-hyva-checkout oder magefan/module-blog lohnt sich dieser fokussierte Blick besonders, weil sie oft eigene, teils enge Versionsconstraints an gemeinsame Bibliotheken wie league/csv oder symfony/console mitbringen.

7. Composer-Lock-Diffs vor dem Merge pruefen

Neben dem grafischen Graphen zeigt PhpStorm composer.lock-Aenderungen auch im normalen Diff-Viewer an, wenn ein Kollege in einem Feature-Branch neue Pakete hinzugefuegt hat. Weil composer.lock eine sehr lange, generierte Datei ist, lohnt es sich, den Diff gezielt auf den packages-Abschnitt zu filtern, statt die komplette Datei zu ueberfliegen.

Ein bewaehrter Workflow vor dem Merge eines Pull Requests: composer.lock im Diff-Viewer oeffnen, neue oder geaenderte Versionsnummern markieren, und fuer jede auffaellige Aenderung kurz den Graphen konsultieren, ob dadurch neue Konfliktknoten entstehen. Das dauert bei einem geuebten Team wenige Minuten und verhindert, dass ein stillschweigend erzwungenes Downgrade einer Bibliothek erst in der Staging-Umgebung auffaellt.

8. Den Graphen mit CI-Pruefungen kombinieren

Der visuelle Graph in PhpStorm ist ein Werkzeug fuer die lokale Analyse, ersetzt aber keine automatisierte Absicherung in der Pipeline. Sinnvoll ist es, composer validate --strict und composer audit als feste Schritte in der CI zu verankern, damit veraltete oder unsichere Paketversionen nicht erst bei der naechsten manuellen Graph-Inspektion auffallen.

In der Praxis ergaenzen sich beide Ebenen: composer audit meldet bekannte Sicherheitsluecken in Abhaengigkeiten automatisiert bei jedem Push, waehrend der Graph in PhpStorm die Frage beantwortet, warum genau eine bestimmte Version im Projekt gelandet ist und welches Paket sie erzwingt. Wer beides kombiniert, bekommt sowohl eine automatisierte Fruehwarnung als auch das Werkzeug, um die Ursache gezielt zu untersuchen.

# CI-Schritt vor dem eigentlichen Build
bin/composer validate --strict
bin/composer audit --format=plain

9. Praxis-Checkliste fuer den naechsten Composer-Upgrade

Vor einem groesseren Magento- oder PHP-Upgrade lohnt sich eine feste Reihenfolge: zuerst composer outdated --direct ausfuehren, um veraltete direkte Abhaengigkeiten zu identifizieren, dann fuer jedes betroffene Paket den Graphen in PhpStorm oeffnen und pruefen, welche transitiven Ketten daran haengen. Erst danach folgt der eigentliche composer update-Versuch in einem isolierten Branch.

Diese Reihenfolge verhindert das haeufigste Muster bei Magento-Upgrades: ein composer update wird gestartet, schlaegt nach mehreren Minuten mit einer unverstaendlichen Konfliktmeldung fehl, und das Team beginnt, einzelne Versionsconstraints zu raten, statt die Ursache zu verstehen. Mit dem Graphen als vorgeschaltetem Analyseschritt laesst sich der Grossteil dieser Iterationen vermeiden.

10. Zusammenfassung

11. FAQ: Composer-Graph in PhpStorm: Das Wichtigste auf einen Blick