Composer: Abhängigkeiten in PHP-Projekten verwalten

Zwei Dateien, zwei Aufgaben

`composer.json` beschreibt, was Sie wollen: welche Pakete und in welchem Spielraum. `composer.lock` hält fest, was dabei herausgekommen ist: jedes Paket mit genau einer Version und einer Prüfsumme.

{ "require": { "php": ">=8.2", "monolog/monolog": "^3.5" }, "require-dev": { "phpunit/phpunit": "^11.0" } }

Bei einer Anwendung gehören beide Dateien in die Versionsverwaltung — auch die Sperrdatei, gerade die. Bei Bibliotheken, die andere als Paket einbinden, wird sie oft weggelassen, weil sie für deren Nutzer ohne Wirkung ist. Sie ist der Grund, warum ein Kollege und der Server denselben Stand bekommen wie Sie.

install und update verwechselt man genau einmal

• `composer install` liest die Sperrdatei und installiert exakt die dort festgehaltenen Versionen. Das ist der Befehl für Kollegen, für die Testumgebung und für den Server.
• `composer update` sucht innerhalb der erlaubten Spielräume neue Versionen, installiert sie und schreibt die Sperrdatei neu. Das ist eine bewusste Entscheidung, die jemand prüfen muss.

Ein `composer update` auf dem Server ist ein Vorgang, dessen Ergebnis niemand vorher gesehen hat. Dasselbe gilt für `composer update` kurz vor einer Auslieferung.

Was im Betrieb zählt

• Auf dem Server gehört `composer install` in den Ausliefervorgang, nicht `update`. Der Schalter `--no-dev` lässt Entwicklungspakete weg. Das ist auf einem Produktivsystem richtig — aber nur, wenn die Anwendung dort wirklich keines davon braucht. `composer dump-autoload -o` erzeugt eine Classmap und beschleunigt den Start; mit `-a` (classmap-authoritative) wird ausschließlich diese Liste verwendet, eine Klasse, die nicht darin steht, wird dann nicht mehr gefunden. Eine Klasse, deren Pfad nicht zur Zuordnung passt, fehlt dann. `composer audit` meldet bekannte Sicherheitslücken in den installierten Paketen. Der Befehl gehört in die regelmäßige Pflege.