NextPDF-Backport-Integration

Build-Werkzeug — KEINE Laufzeitabhängigkeit. Maintainer verwenden dieses Paket, um die PHP-7.4- und PHP-8.1-Backport-Distributionen von NextPDF zu erzeugen. Anwendungen dürfen dieses Paket niemals als Laufzeitabhängigkeit einbinden.

Auf einen Blick

Es gibt zwei klar getrennte Integrationspunkte. Der Build-Host bindet das Builder-Repository in einen Release-Ablauf ein. Die nachgelagerte Anwendung bindet das erzeugte Paket, nextpdf/backport, in ihren Abhängigkeitsbaum ein. Der Builder gelangt niemals in den Abhängigkeitsbaum einer Anwendung.

Installation (nur Build-Hosts)

Der Builder deklariert "type": "project" in composer.json; er ist also ein Projekt-Repository und keine Bibliothek. Integrieren Sie ihn über einen Klon mit anschließender Dev-Installation, nicht über composer require:

git clone https://github.com/nextpdf-labs/backport.git
cd backport
git checkout PHP74
composer install --prefer-dist --no-progress

Checken Sie den Branch für das Target aus, das Sie erzeugen möchten. Verwenden Sie PHP74 (den Standard) für die reine Core-Distribution für PHP 7.4. Verwenden Sie PHP81 für die PHP-8.1-Distribution mit allen Adaptern. Übergeben Sie nicht --no-dev. Der Build benötigt die Rector-Engine, PHPStan und PHPUnit; diese sind Dev-Abhängigkeiten. Verifiziert anhand von composer.json (type, require-dev) und des Dual-Branch-Modells in /integrations/backport/overview/.

Boot und Auto-Discovery

Es gibt keine Framework-Auto-Discovery. Zur Build-Zeit verdrahtet scripts/build.php Rector und die drei benutzerdefinierten Abstract-Syntax-Tree-Regeln über explizites require_once und das PSR-4-Autoloading von Composer. Die vollständige Boot-Sequenz und die Discovery der Quellmodule sind in /integrations/backport/boot-and-discovery/ dokumentiert.

Container-Bindungen

Nicht zutreffend. Der Builder ist ein CLI-Werkzeug ohne Dependency-Injection-Container. Verifiziert anhand der Repository-Struktur und von composer.jsonautoload.

Publish-Konfiguration

Die „Publish-Konfiguration“ ist keine eigene Datei. Sie besteht aus der Menge der Build-Flags plus den festen Paketdefinitionen in scripts/adjust-composer.php:

• Target-Map. --target=php81 erzeugt nextpdf/backport (Constraint >=8.1 <8.5, ersetzt Core plus die Adapter plus compat-legacy) und, sofern einbezogen, nextpdf/backport-pro. --target=php74 erzeugt nextpdf/backport (Constraint >=7.4 <8.1, ersetzt nur nextpdf/core) und kein Pro.
• Ausschluss. --no-pro schließt das Pro-Paket für das PHP-8.1-Target aus. Das PHP-7.4-Target schließt Pro und alle Adapter konstruktionsbedingt aus.
• Version. Der Build schreibt --version (oder den Release-Tag ohne führendes v) in die generierte composer.json und CHANGELOG.md.

Verifiziert anhand von scripts/build.php und scripts/adjust-composer.php (generatePublicComposer(), generateProComposer(), buildReplace()). Die vollständige Flag-Referenz befindet sich in /integrations/backport/configuration/.

Release-Ablauf-Integration

Der Builder wird über die GitHub-Actions-Workflows in .github/workflows/ in einen Release-Ablauf eingebunden. 0-ci.yml prüft jede Änderung an einem der beiden permanenten Branches mit PHPStan, den Regeltests und einem Dry-Run. build.yml erzeugt und veröffentlicht die Distribution bei einem source-release-Repository-Dispatch-Event oder bei einem manuellen Dispatch. Das vollständige Betriebsmodell — Trigger, Lanes, Validierungsmatrix und gemeinsamer Release — ist in /integrations/backport/production-usage/ dokumentiert.

Smoke-Test der Ausgabe-Konsumierung

Die Release-Pipeline ist der Integrations-Smoke-Test. Nach dem Build schaltet der Workflow den Runner auf das Ziel-PHP um und führt php -l über den ausgegebenen Quellcode aus. Anschließend installiert er das erzeugte Paket und führt es über die Validierungsmatrix hinweg aus (PHP 8.1–8.4 für die PHP-8.1-Lane, PHP 7.4 und 8.0 für die PHP-7.4-Lane). Eine Distribution, die eine Ziel-Laufzeitumgebung ablehnen würde, erreicht keinen Release. Verifiziert anhand von .github/workflows/build.yml (den Syntax-Check- und validate-*-Jobs). Sie können die lokal erzeugte Ausgabe auf die gleiche Weise mit dem Docker-Befehl smoke-testen, den die Validierungsstufe ausgibt — siehe /integrations/backport/quickstart/.

Öffentliche Einstiegspunkte

Die öffentliche Oberfläche des Builders besteht aus dem CLI-Orchestrator und seinen Composer-Skript-Aliassen, nicht aus einer ausführbaren Datei in bin/.

Einstiegspunkt	Wird aufgelöst zu	Zweck
composer build	php scripts/build.php	Vollständiger Build
composer build:dry	php scripts/build.php --dry-run	Dry-Run-Build
composer test	phpunit	Regel-Fixture-Suites
composer analyse	phpstan analyse rector/rules scripts --level=10	Statische Analyse des Build-Codes

Verifiziert anhand von composer.jsonscripts. Die Einstiegspunkte des nachgelagerten Pakets sind die ursprünglichen NextPDF\-API-Symbole; sie bleiben durch den Backport unverändert. Das Paket ersetzt die Quellpakete und lädt den zusammengeführten Baum automatisch über das einzige PSR-4-Präfix.

Siehe auch

• /integrations/backport/overview/ — was der Builder ist und was er erzeugt.
• /integrations/backport/boot-and-discovery/ — Boot-Sequenz und Quell-Discovery.
• /integrations/backport/install/ — Build-Host- und nachgelagerte Installation.
• /integrations/backport/production-usage/ — die Release-Pipeline.