Intégration du backport NextPDF

Outillage de build — PAS une dépendance d’exécution. Les mainteneurs utilisent ce paquet pour produire les distributions de backport NextPDF pour PHP 7.4 et PHP 8.1. Les applications ne doivent jamais déclarer ce paquet comme dépendance d’exécution.

En un coup d’œil

Il existe deux points d’intégration distincts. L’hôte de build intègre le dépôt du constructeur dans un flux de publication. L’application en aval intègre le paquet produit, nextpdf/backport, dans son arbre de dépendances. Le constructeur ne rejoint jamais l’arbre de dépendances d’une application.

Installation (hôtes de build uniquement)

Comme le constructeur déclare "type": "project" dans composer.json, il s’agit d’un dépôt de projet, pas d’une bibliothèque. Intègre-le par clonage, puis par une installation dev, et non avec un composer require :

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

Bascule sur la branche correspondant à la cible à produire. Utilise PHP74 (la valeur par défaut) pour la distribution PHP 7.4 limitée au cœur. Utilise PHP81 pour la distribution PHP 8.1 avec tous les adaptateurs. Ne passe pas --no-dev. Le build a besoin du moteur Rector, de PHPStan et de PHPUnit, qui sont des dépendances dev. Vérifié à partir de composer.json (type, require-dev) et du modèle à deux branches dans /integrations/backport/overview/.

Amorçage et découverte automatique

Aucune découverte automatique n’est effectuée par le framework. Au moment du build, scripts/build.php branche Rector et les trois règles personnalisées sur l’arbre syntaxique abstrait via des require_once explicites et l’autoloading PSR-4 de Composer. La séquence d’amorçage complète et la découverte des modules source sont documentées dans /integrations/backport/boot-and-discovery/.

Liaisons de conteneur

Non applicable. Le constructeur est un outil CLI sans conteneur d’injection de dépendances. Vérifié à partir de la structure du dépôt et de composer.jsonautoload.

Configuration de publication

La « configuration de publication » n’est pas un fichier. Elle correspond à l’ensemble des drapeaux de build et aux définitions de paquets figées dans scripts/adjust-composer.php :

• Carte des cibles. --target=php81 produit nextpdf/backport (contrainte >=8.1 <8.5, remplace le cœur, les adaptateurs et compat-legacy) ainsi que, lorsqu’il est inclus, nextpdf/backport-pro. --target=php74 produit nextpdf/backport (contrainte >=7.4 <8.1, remplace uniquement nextpdf/core) et pas de Pro.
• Exclusion. --no-pro exclut le paquet Pro sur la cible PHP 8.1. La cible PHP 7.4 exclut Pro et tous les adaptateurs par construction.
• Version. Le build écrit --version (ou le tag de release sans son v initial) dans le composer.json généré et le CHANGELOG.md.

Vérifié à partir de scripts/build.php et scripts/adjust-composer.php (generatePublicComposer(), generateProComposer(), buildReplace()). La référence complète des drapeaux se trouve dans /integrations/backport/configuration/.

Intégration au flux de publication

Le constructeur s’intègre à un flux de publication via les workflows GitHub Actions dans .github/workflows/. 0-ci.yml contrôle chaque changement vers l’une ou l’autre des branches permanentes avec PHPStan, les tests de règles et une exécution à blanc. build.yml produit et publie la distribution sur un événement repository-dispatch source-release ou sur un déclenchement manuel. Le modèle de fonctionnement complet — déclencheurs, voies, matrice de validation et release partagée — est documenté dans /integrations/backport/production-usage/.

Test de fumée de consommation de la sortie

Le pipeline de publication sert de test de fumée d’intégration. Après le build, le workflow bascule l’exécuteur sur la version PHP cible et lance php -l sur le code source émis. Il installe ensuite le paquet produit et le met à l’épreuve sur la matrice de validation (PHP 8.1–8.4 pour la voie PHP 8.1, PHP 7.4 et 8.0 pour la voie PHP 7.4). Une distribution qu’un runtime cible rejetterait n’atteint pas une release. Vérifié à partir de .github/workflows/build.yml (les tâches de vérification de syntaxe et validate-*). Tu peux effectuer localement le même test de fumée sur la sortie produite avec la commande Docker imprimée par l’étape de validation — voir /integrations/backport/quickstart/.

Points d’entrée publics

La surface publique du constructeur correspond à l’orchestrateur CLI et à ses alias de scripts Composer, pas à un exécutable bin/.

Point d’entrée	Se résout en	Objet
composer build	php scripts/build.php	Build complet
composer build:dry	php scripts/build.php --dry-run	Build à blanc
composer test	phpunit	Suites de fixtures de règles
composer analyse	phpstan analyse rector/rules scripts --level=10	Analyse statique du code de build

Vérifié à partir de composer.jsonscripts. Les points d’entrée du paquet en aval sont les symboles d’API NextPDF\ d’origine, inchangés par le backport. Le paquet remplace les paquets source et charge automatiquement l’arbre fusionné via l’unique préfixe PSR-4.

Voir aussi

• /integrations/backport/overview/ — ce qu’est le constructeur et ce qu’il produit.
• /integrations/backport/boot-and-discovery/ — séquence d’amorçage et découverte du code source.
• /integrations/backport/install/ — installation côté hôte de build et côté aval.
• /integrations/backport/production-usage/ — le pipeline de publication.