Composer installieren und benutzen: der komplette Guide

Composer ist der Abhängigkeitsmanager von PHP. Er installiert die Bibliotheken, die ein Projekt braucht, löst deren eigene Abhängigkeiten auf, friert die Versionen ein und erzeugt das Autoloading der Klassen. Dieses Tutorial deckt die Installation auf allen drei Systemen ab, dazu die Befehle für den Alltag und die Fehler, die Zeit kosten. Geprüft mit Composer 2.10.3 auf PHP 8.5.10.

Installieren, mit Signaturprüfung

Das Rezept, das man überall sieht, lautet curl -sS https://getcomposer.org/installer | php. Es führt eine gerade heruntergeladene Datei direkt aus, ohne irgendetwas zu prüfen. Die offizielle Prozedur vergleicht die SHA-384-Prüfsumme des Skripts mit der, die das Projekt veröffentlicht, bevor sie es startet.

#!/usr/bin/env bash
set -euo pipefail

ATTENDU=$(curl -sS https://composer.github.io/installer.sig)
curl -sS https://getcomposer.org/installer -o composer-setup.php
CALCULE=$(php -r "echo hash_file('sha384', 'composer-setup.php');")

if [ "$ATTENDU" != "$CALCULE" ]; then
    >&2 echo 'ERREUR : signature invalide, ne pas exécuter'
    rm composer-setup.php
    exit 1
fi

php composer-setup.php --quiet --install-dir=/usr/local/bin --filename=composer
rm composer-setup.php
composer --version

Composer version 2.10.3 2026-08-27 13:34:23

Beide Prüfsummen stimmen überein, der Installer ist echt. Das sind dreißig Sekunden Mehrarbeit gegen die Ausführung eines beliebigen Skripts mit den Rechten deines Kontos.

Windows

Composer-Setup.exe herunterladen und ausführen. Der Installer erkennt PHP, richtet den PATH ein und aktualisiert sich selbst.

macOS

Das Skript von oben funktioniert unverändert. Mit Homebrew:

brew install composer

Eine Anmerkung zu älteren Tutorials: Sie verlangen einen Alias in ~/.bash_profile. Seit macOS Catalina (2019) ist zsh die Standard-Shell, und diese Datei wird nicht mehr gelesen. Zu ändern ist ~/.zshrc. Der Alias ist ohnehin überflüssig, wenn composer.phar mit Ausführungsrecht unter /usr/local/bin/composer liegt.

Linux

sudo apt-get update
sudo apt-get install -y php-cli unzip curl
# dann das Prüfskript von oben

Das Paket composer aus den Debian- und Ubuntu-Repositories hinkt oft mehrere Versionen hinterher. Der offizielle Installer ist die bessere Wahl.

Ein Projekt starten

mkdir mon-projet && cd mon-projet
composer init          # interaktiver Fragebogen
composer require monolog/monolog

Dieser Befehl legt drei Dinge an oder aktualisiert sie:

• composer.json, was du anforderst. Kommt in die Versionsverwaltung.
• composer.lock, die exakt installierten Versionen, auf den Commit genau. Kommt ebenfalls in die Versionsverwaltung, das garantiert, dass das ganze Team und die Produktion denselben Code haben.
• vendor/, die heruntergeladenen Dateien. Wird nicht versioniert, gehört in die .gitignore.

/vendor/

install oder update: der Unterschied, auf den es ankommt

composer update auf einem Produktionsserver zu starten, installiert Versionen, die niemand getestet hat. Das ist die Ursache einer bemerkenswerten Zahl gescheiterter Deployments.

# Ein einzelnes Paket aktualisieren
composer update monolog/monolog

# Ein Paket samt seinen Abhängigkeiten aktualisieren
composer update monolog/monolog --with-dependencies

# Sehen, was sich ändern würde, ohne etwas zu ändern
composer update --dry-run

Die Versionsbeschränkungen

{
    "require": {
        "php": ">=8.2",
        "monolog/monolog": "^3.5",
        "symfony/console": "~6.4.0",
        "vendor/paquet": "2.1.3"
    }
}

Das ^ ist die richtige Voreinstellung: Es lässt Korrekturen und Ergänzungen zu und verweigert Kompatibilitätsbrüche. Eine exakte Version festzuschreiben wirkt vorsichtig, blockiert aber die Sicherheitspatches.

Die PHP-Version in require zu deklarieren verhindert, dass du ein Paket installierst, das auf dem Server nicht läuft. Und wenn der Entwicklungsrechner nicht dieselbe Version hat wie die Produktion, lässt config.platform die Abhängigkeiten für die Zielversion auflösen:

{
    "config": {
        "platform": {
            "php": "8.4.0"
        }
    }
}

Das Autoloading

Das ist die nützlichste Funktion von Composer und die, die man zuletzt entdeckt. Der Standard PSR-4 verbindet ein Namespace-Präfix mit einem Verzeichnis.

{
    "autoload": {
        "psr-4": {
            "App\\": "src/",
            "App\\Tests\\": "tests/"
        },
        "files": [
            "src/fonctions.php"
        ]
    }
}

Backslashes werden in einer JSON-Datei verdoppelt. Das ist der häufigste Fehler in dieser Datei, und er bleibt stumm, bis Composer sich weigert, sie zu lesen:

"App\": "src/"     -> JSON INVALIDE (l'antislash échappe le guillemet)
"App\\": "src/"    -> correct

Mit dieser Konfiguration wird die Klasse App\Personnages\Guerrier in src/Personnages/Guerrier.php gesucht. Der Pfad ergibt sich aus dem Namen: Backslashes im Code, Schrägstriche in den Verzeichnissen.

<?php

declare(strict_types=1);

namespace App\Personnages;   // Backslashes, nie Schrägstriche

final class Guerrier
{
    // …
}

<?php

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

use App\Personnages\Guerrier;

$conan = new Guerrier();

Nach jeder Änderung am Abschnitt autoload:

composer dump-autoload

Keine Kommentare in composer.json

JSON kennt keine Kommentare. Ein //, das sich in die Datei verirrt, macht sie unlesbar:

In JsonFile.php line 398:
  "./composer.json" does not contain valid JSON
  Lexical error on line 5. Comments are not allowed.

Der Befehl composer validate prüft die Datei, bevor das Problem an anderer Stelle auftaucht.

Sicherheitslücken prüfen

composer audit gleicht die installierten Pakete mit der Datenbank der Sicherheitshinweise des PHP-Ökosystems ab.

composer audit

No security vulnerability advisories found.

Dieser Befehl gehört in die Continuous Integration, nach composer install: Ohne vendor/-Ordner antwortet er nur „No installed packages found“. Er liefert einen Exit-Code ungleich null, wenn ein Hinweis das Projekt betrifft.

Aufgegebene Pakete erkennen

Composer meldet bei der Installation die Pakete, deren Autor sie für aufgegeben erklärt hat. Der Hinweis geht im Ausgabestrom oft unter:

Package facebook/php-sdk is abandoned, you should avoid using it.
Use facebook/graph-sdk instead.

Ein aufgegebenes Paket bekommt keine Korrekturen mehr, auch keine sicherheitsrelevanten. Bei dieser Meldung lohnt es sich anzuhalten, statt sie durchlaufen zu lassen.

In Produktion deployen

composer install --no-dev --optimize-autoloader --no-interaction --prefer-dist

Und eine Regel, die eine Wiederholung wert ist: Composer nie mit sudo starten. Die Dateien in vendor/ würden root gehören, der Webserver könnte sie nicht mehr lesen, und der Cache von Composer landete in /root/.composer. Wenn die globale Installation sudo verlangt, dann nur, um einmal nach /usr/local/bin zu schreiben.

Die Befehle für den Alltag

# Was installiert ist
composer show
composer show monolog/monolog        # Details zu einem Paket
composer show --tree                 # Abhängigkeitsbaum

# Was aktualisiert werden könnte
composer outdated
composer outdated --direct           # nur deine direkten Abhängigkeiten

# Warum ist dieses Paket da?
composer why psr/log
composer why-not symfony/console 7.0 # was ein Versions-Upgrade blockiert

# Ein Paket entfernen
composer remove monolog/monolog

# Eine fragwürdige Installation reparieren
rm -rf vendor composer.lock && composer install

Zwei Flags aus Composer 1 geistern noch durch die Tutorials. composer show -i liefert inzwischen eine Warnung, weil die installierten Pakete längst die Standardanzeige sind:

You are using the deprecated option "installed". Only installed packages are
shown by default now. The --all option can be used to show all packages.

Und composer --V gibt es nicht, es heißt -V oder --version:

The "--V" option does not exist.

Besondere Paketquellen

{
    "require": {
        "moi/mon-paquet": "dev-main"
    },
    "repositories": [
        {
            "type": "vcs",
            "url": "https://github.com/moi/mon-paquet"
        }
    ]
}

Wenn du ein Paket parallel zu dem Projekt entwickelst, das es benutzt, legt ein Repository vom Typ path einen Symlink an: Die Änderungen sind sofort sichtbar, ohne Neuinstallation.

{
    "repositories": [
        {
            "type": "path",
            "url": "../mes-paquets/mon-paquet",
            "options": {
                "symlink": true
            }
        }
    ]
}

Die Skripte

{
    "scripts": {
        "test": "phpunit",
        "analyse": "phpstan analyse src --level=8",
        "verifier": [
            "@analyse",
            "@test"
        ]
    }
}

composer verifier

Das erspart dir, die Pfade nach vendor/bin im Kopf zu behalten, und gibt dem ganzen Team dieselben Befehle.

Zum Mitnehmen

• Die Prüfsumme des Installers vergleichen, bevor du ihn ausführst.
• composer.lock versionieren, vendor/ ignorieren.
• install in Produktion, update nur in der Entwicklung.
• Backslashes in composer.json verdoppeln, keine Kommentare.
• composer audit in der Continuous Integration, nie sudo.

Composer ist das Einfallstor zu den meisten Bibliotheken: PHPMailer zum Versenden einer E-Mail und Ratchet für einen WebSocket-Server installierst du beide mit composer require.

Weiter geht es mit den Best Practices für Composer, den Grundlagen der OOP in PHP, um das Autoloading auszureizen, und dem Hub Webentwicklung.