Composer ist ein Paket- und Abhängigkeitsmanager für PHP.
Mit Composer werden PHP-Bibliotheken und Frameworks installiert, aktualisiert und verwaltet.
In meinen Projekten wird Composer insbesondere für Laravel und damit für die Entwicklung von RoWaBase eingesetzt.
Die installierte Composer-Version kann in der Kommandozeile geprüft werden:
composer --version
Kurzform:
composer -V
Ein PHP-Projekt kann von zahlreichen externen Paketen abhängig sein.
Composer verwaltet:
Die wichtigsten Bestandteile sind:
composer.json composer.lock vendor/
Die Datei composer.json beschreibt die Anforderungen des Projekts.
Sie befindet sich normalerweise im Stammverzeichnis.
Beispiel:
E:\xampp\htdocs\rowabase\composer.json
Darin werden unter anderem die benötigte PHP-Version und die verwendeten Pakete definiert.
Ein vereinfachtes Beispiel:
{
"require": {
"php": "^8.2",
"laravel/framework": "^12.0"
}
}
Die Datei composer.json gehört zur Projektdefinition und wird deshalb mit Git versioniert.
Die Datei composer.lock enthält die konkret aufgelösten Paketversionen.
Während composer.json beispielsweise einen zulässigen Versionsbereich beschreiben kann, hält composer.lock fest, welche Version tatsächlich installiert wurde.
Dadurch können verschiedene Entwicklungsumgebungen denselben Paketstand verwenden.
Die Datei:
composer.lock
sollte bei Anwendungen wie RoWaBase ebenfalls mit Git versioniert werden.
Composer installiert die PHP-Pakete standardmäßig in:
vendor/
Dieses Verzeichnis kann sehr viele Dateien enthalten.
Es wird normalerweise nicht mit Git versioniert.
Bei Laravel befindet sich deshalb typischerweise folgender Eintrag in .gitignore:
/vendor
Die benötigten Dateien können anhand von composer.json und composer.lock jederzeit wieder installiert werden.
Sind composer.json und composer.lock vorhanden, werden die festgelegten Pakete installiert mit:
composer install
Composer verwendet dabei die in composer.lock festgelegten Versionen.
Dieser Befehl ist beispielsweise wichtig, nachdem ein bestehendes Projekt auf einen anderen Rechner kopiert oder aus einem Git-Repository ausgecheckt wurde.
install und update haben unterschiedliche Aufgaben.
Installieren des festgelegten Projektstands:
composer install
Dabei werden möglichst genau die Versionen aus composer.lock installiert.
Abhängigkeiten aktualisieren:
composer update
Dabei löst Composer die Abhängigkeiten anhand der Regeln in composer.json neu auf und aktualisiert anschließend auch composer.lock.
composer update sollte nicht einfach routinemäßig ausgeführt werden.
Es kann zahlreiche Paketversionen verändern und damit einen größeren technischen Eingriff in das Projekt darstellen.
Ein zusätzliches PHP-Paket wird mit require in das Projekt aufgenommen:
composer require hersteller/paket
Composer:
composer.jsoncomposer.lock
Die Änderungen an composer.json und composer.lock sollten anschließend gemeinsam mit dem dazugehörigen Anwendungscode in Git gespeichert werden.
Pakete, die nur während der Entwicklung benötigt werden, können als Entwicklungsabhängigkeit installiert werden:
composer require --dev hersteller/paket
Sie erscheinen in composer.json unter:
require-dev
Typische Beispiele sind Test-, Analyse- oder Entwicklungswerkzeuge.
Ein installiertes Paket kann entfernt werden mit:
composer remove hersteller/paket
Composer passt dabei die Projektabhängigkeiten entsprechend an.
Eine Übersicht der installierten Composer-Pakete:
composer show
Informationen zu einem bestimmten Paket:
composer show hersteller/paket
Mit:
composer outdated
kann geprüft werden, für welche installierten Pakete neuere Versionen verfügbar sind.
Das bedeutet jedoch nicht automatisch, dass alle angezeigten Pakete sofort aktualisiert werden sollten.
Vor Aktualisierungen sollten insbesondere Kompatibilität und Auswirkungen auf die Anwendung geprüft werden.
Composer stellt einen Autoloader für PHP-Klassen bereit.
Dadurch müssen Klassen nicht einzeln mit require oder include eingebunden werden.
Laravel verwendet dieses Verfahren intensiv.
Die Zuordnung der eigenen Anwendungsklassen wird unter anderem in composer.json beschrieben.
Typisch für Laravel:
"autoload": {
"psr-4": {
"App\\": "app/",
"Database\\Factories\\": "database/factories/",
"Database\\Seeders\\": "database/seeders/"
}
}
Dadurch kann beispielsweise:
App\Models\Objekt
automatisch der entsprechenden PHP-Datei unter app/ zugeordnet werden.
Nach bestimmten Änderungen an Klassen oder Autoload-Konfigurationen kann der Autoloader neu aufgebaut werden:
composer dump-autoload
Normalerweise ist dieser Schritt bei der täglichen Laravel-Entwicklung nicht nach jeder Änderung erforderlich.
Bei Problemen mit der Composer-Installation oder Umgebung kann eine Diagnose durchgeführt werden:
composer diagnose
Composer prüft dabei verschiedene Aspekte der lokalen Konfiguration.
Die composer.json und teilweise auch der zugehörige Lock-Stand können geprüft werden mit:
composer validate
Dies ist insbesondere nach manuellen Änderungen an composer.json sinnvoll.
Composer selbst benötigt PHP.
Deshalb hängen Composer-Probleme häufig auch mit der verwendeten PHP-Version oder fehlenden PHP-Extensions zusammen.
PHP-Version prüfen:
php -v
Geladene Extensions anzeigen:
php -m
Verwendete PHP-Konfiguration anzeigen:
php --ini
Weitere Informationen:
Laravel wird über Composer verwaltet.
Die Laravel-Komponenten und weitere PHP-Abhängigkeiten eines Projekts befinden sich im vendor-Verzeichnis.
Artisan lädt diese Abhängigkeiten über den von Composer erzeugten Autoloader.
Fehlt vendor/, funktionieren Laravel-Befehle deshalb nicht.
In diesem Fall werden die Abhängigkeiten normalerweise wiederhergestellt mit:
composer install
Weitere Informationen:
Bei einem mit Composer verwalteten Anwendungsprojekt werden normalerweise versioniert:
composer.json composer.lock
Nicht versioniert wird:
vendor/
Damit speichert Git die Definition des Paketstands, aber nicht tausende installierte Fremddateien.
Weitere Informationen:
Im RoWaBase-Projekt befinden sich im Stammverzeichnis:
composer.json composer.lock
Das Verzeichnis:
vendor/
wird dagegen über .gitignore von der Versionsverwaltung ausgeschlossen.
Damit lässt sich die PHP-Umgebung eines RoWaBase-Projektstands grundsätzlich wiederherstellen:
composer install
Composer liest composer.lock und installiert die dort festgelegten Abhängigkeiten erneut.
composer require hersteller/paket git status
Danach werden die Änderungen und ihre Auswirkungen geprüft.
Typischerweise haben sich mindestens folgende Dateien geändert:
composer.json composer.lock
Erst wenn das neue Paket in der Anwendung getestet wurde, sollte der gesamte fachlich zusammengehörige Stand mit Git gesichert werden.
composer --version composer install composer require hersteller/paket composer require --dev hersteller/paket composer remove hersteller/paket composer show composer outdated composer dump-autoload composer validate composer diagnose
composer.json beschreibt, was das Projekt benötigt.
composer.lock hält fest, welche Versionen tatsächlich zum Projektstand gehören.
vendor/ enthält die daraus installierten Pakete und wird normalerweise nicht mit Git gespeichert.