composer.json: die PHP-Pakete

{
    "name": "local/typo3-appliance",
    "description": "TYPO3 Docker Appliance",
    "type": "project",
    "license": "GPL-2.0-or-later",
    …
}

Composer ist der Paketmanager für PHP. composer.json legt fest, welche Pakete in welchen Versionsbereichen installiert werden. Das ist der empfohlene Weg, TYPO3 zu installieren: Core, Systemextensions und Erweiterungen sind normale Composer-Pakete.

Der Typ project kennzeichnet eine Anwendung, die nicht selbst als Bibliothek eingebunden wird. Die Lizenz GPL-2.0-or-later entspricht der von TYPO3.

"repositories": [
    {
        "type": "path",
        "url": "packages/*"
    }
],

Neben dem öffentlichen Verzeichnis Packagist sucht Composer Pakete auch in packages/. Jeder Unterordner mit eigener composer.json wird zum Paket, hier local/oidc-backend und local/site-package.

Pfad-Pakete installiert Composer als symbolischen Link: vendor/local/site-package zeigt auf packages/site_package. Eine neue eigene Extension legt man als Ordner an und bindet sie ein:

docker compose run --rm --no-deps --entrypoint "" -v "$PWD:/app" -w /app php \
    composer require local/meine-extension:@dev --no-install
docker compose up -d --build

"require": {
    "php": "^8.4",
    "causal/oidc": "^6.0",
    "local/oidc-backend": "@dev",
    "local/site-package": "@dev",
    "typo3/cms-backend": "^14.3",
    "typo3/cms-core": "^14.3",
    …
},

Die Versionsangaben folgen dem Semantic Versioning:

• ^14.3 erlaubt alle Versionen ab 14.3.0 unter 15.0.0, also Bugfix- und Feature-Updates von TYPO3 14, aber keinen Sprung auf eine neue Hauptversion.
• "php": "^8.4" ist kein Paket, sondern eine Bedingung: Composer verweigert die Installation unter einer älteren PHP-Version.
• @dev erlaubt beim lokalen Paket jeden Entwicklungsstand. Pfad-Pakete haben keine veröffentlichten Versionen.

Die Pakete im Einzelnen:

Nicht benötigte Systemextensions lassen sich hier streichen. Ein Rebuild entfernt sie dann.

"config": {
    "allow-plugins": {
        "typo3/class-alias-loader": true,
        "typo3/cms-composer-installers": true
    },
    "sort-packages": true
},
"extra": {
    "typo3/cms": {
        "web-dir": "public"
    }
},
"minimum-stability": "stable",
"prefer-stable": true

• allow-plugins: Composer führt Plugins nur aus, wenn sie ausdrücklich erlaubt sind. typo3/cms-composer-installers erzeugt den Webroot public/ mit index.php und verlinkt die öffentlichen Dateien der Extensions nach public/_assets. typo3/class-alias-loader stellt alte Klassennamen als Aliase bereit, damit ältere Extensions weiterlaufen.
• sort-packages: composer require hält die Liste unter require alphabetisch sortiert.
• web-dir: der öffentliche Ordner, den nginx als Document Root ausliefert. Alles außerhalb, etwa vendor/, config/ und var/, ist aus dem Web nicht erreichbar.
• minimum-stability und prefer-stable: nur stabile Versionen, keine Betas oder Entwicklungsstände. Ausnahmen wie @dev für die lokalen Pakete gelten nur dort, wo sie ausdrücklich stehen.

# verfügbare Updates anzeigen
docker compose run --rm --no-deps --entrypoint "" -v "$PWD:/app" -w /app php \
    composer outdated "typo3/*"

# TYPO3 innerhalb von ^14.3 aktualisieren, nur composer.lock neu schreiben
docker compose run --rm --no-deps --entrypoint "" -v "$PWD:/app" -w /app php \
    composer update "typo3/*" --with-all-dependencies --no-install

# Images mit den neuen Versionen bauen und starten
docker compose up -d --build

composer.json nennt erlaubte Versionsbereiche, composer.lock die exakt installierten Versionen samt Prüfsummen. Der Build installiert immer genau den Stand der Lock-Datei. Deshalb gehört sie ins Repository, und deshalb sehen alle Rechner und jede Wiederherstellung identische Versionen.

Ein Update ändert zuerst nur die Lock-Datei. --no-install verhindert, dass Composer im Projektordner ein lokales vendor/ anlegt, das im Image ohnehin keine Rolle spielt. Erst der Rebuild bringt die neuen Versionen in die Images. Beim Start passt der Entrypoint das Datenbankschema an.