Composer und Paketverwaltung in PHP

Erste Schritte: Composer und Paketverwaltung in PHP

Composer ist der De‑facto‑Standard für Paketverwaltung und Autoloading in PHP.
Er lädt Bibliotheken (Dependencies), generiert einen Autoloader (PSR‑4) und hält Versionen konsistent.
Dieses Tutorial zeigt, wie du Composer installierst, Pakete hinzufügst, den Autoloader nutzt
und eigene Pakete veröffentlichst – alles mit Beispielbefehlen im <pre>‑Block.

1. Installation – einmalig pro System

# Linux / macOS (global)
/usr/bin/php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
/usr/bin/php composer-setup.php --install-dir=/usr/local/bin --filename=composer
composer --version

# Windows
# Offizielles Setup‑EXE herunterladen  https://getcomposer.org

2. Neues Projekt initialisieren

mkdir meinprojekt
cd meinprojekt
composer init          # interaktiver Assistent (Name, Beschreibung, Lizenz …)

/* Ergebnis: composer.json */
{
  "name": "ich/meinprojekt",
  "description": "Demo",
  "require": {}
}

3. Paket hinzufügen – composer require

Beispiel: Monolog (Logging‑Bibliothek) installieren.

composer require monolog/monolog
  • Lädt Paket + Abhängigkeiten in vendor/.
  • Schreibt Eintrag in composer.json → require und konkrete Version in composer.lock.

3.1 require‑dev

composer require --dev phpunit/phpunit

Pakete nur für Entwicklung (Tests, Faker, Psalm …) landen in require-dev.

4. Autoloader einbinden

<?php
require __DIR__ . '/vendor/autoload.php';

use Monolog\Logger;
use Monolog\Handler\StreamHandler;

$log = new Logger('app');
$log->pushHandler(new StreamHandler(__DIR__.'/app.log', Logger::INFO));
$log->info('Hello Composer');
?>

Autoloading funktioniert, weil Composer beim Installieren eine Datei
vendor/autoload.php generiert, die PSR‑4‑Konventionen abbildet.

5. Version Constraints (SemVer)

Constraint Beispiel Bedeutung
^1.2 ^1.2 >=1.2.0 <2.0.0
~1.2 ~1.2 >=1.2.0 <1.3.0
>=1.2 <2.0 >=1.2 <2.0 manuelle Ober/Untergrenze

6. composer.lock vs. composer.json

  • composer.json – deklarative Wunsch­versionen (^ / ~ etc.).
  • composer.lock – exakte installierte Versionen.
    Teams committen die lock‑Datei, damit jedes Deployment identische Versionen nutzt.

6.1 install vs. update

composer install   # liest composer.lock, gleiche Versionen
composer update    # ignoriert Lock, holt neueste Version innerhalb Constraint

7. Eigene PSR‑4 Autoload‑Namespaces

{
  "autoload": {
    "psr-4": {
      "App\\": "src/"
    }
  }
}

Danach: composer dump-autoload (oder composer install) erzeugt frischen Autoloader.
Klasse App\Service\Mail ➔ src/Service/Mail.php.

8. Composer Scripts

{
  "scripts": {
    "test": "phpunit",
    "post-update-cmd": "php vendor/bin/psalm --shepherd"
  }
}

composer test ruft das Script auf; Hooks wie post-update-cmd laufen automatisch nach update.

9. Eigenes Paket veröffentlichen

  1. Legen Git‑Repo (GitHub, GitLab …).
  2. composer.json mit name, description, autoload ausstatten.
  3. Tag / Release erstellen (git tag v1.0.0).
  4. Auf packagist.org neuen Paket­eintrag anlegen (oder GitHub Actions für Auto‑Push).

10. Häufige Befehle Kurzliste

composer install           # Pakete laut lock
composer update            # Pakete innerhalb Constraints aktualisieren
composer require paket     # Paket hinzufügen
composer remove  paket     # entfernen
composer dump-autoload     # neuen Autoloader bauen
composer outdated          # veraltete Pakete anzeigen
composer show              # installierte Pakete
composer exec ...          # Befehl im Vendor‑Bin‑Pfad ausführen

Fazit

Composer löst Versions­hölle, Autoloading und Skript­Automatisierung in einem.
Mit composer.json deklarierst du Abhängigkeiten, composer install holt sie exakt,
und vendor/autoload.php macht require‑Orgeln überflüssig.
So entwickelst du modular, update‑fähig und verteilbar – egal ob kleines Hobby‑Projekt oder Enterprise‑Codebase.