Boot e discovery del backport NextPDF

Strumenti di build — NON una dipendenza di runtime. Questo documento descrive come il builder viene avviato su un host di manutenzione o in CI. Le applicazioni a valle non caricano mai questo codice.

In breve

Il builder non dispone di framework, container di dependency injection né auto-discovery dei service provider. È un insieme di script CLI PHP collegati tramite require_once e l’autoloader PSR-4 di Composer. Qui per «discovery» si intendono due aspetti concreti: quali repository sorgente legge la fase di merge e come l’orchestratore seleziona la configurazione di Rector per il target.

Panoramica della pipeline di build

L’orchestratore è scripts/build.php. All’avvio esegue cinque fasi in ordine. Ogni fase è soggetta a gate, quindi il primo errore interrompe la build:

1. Merge dei sorgenti — copia i repository sorgente in un unico albero.
2. Esecuzione del downgrade Rector — un passaggio singolo per PHP 8.1; due passaggi più correzioni per PHP 7.4.
3. Generazione di composer.json — scrive il manifest del pacchetto prodotto con la relativa mappa replace.
4. Copia degli asset statici — copia la licenza e un changelog generato.
5. Validazione dell’output — conta i file PHP emessi; il gate di sintassi autoritativo viene eseguito più avanti nella CI.

Verificato su scripts/build.php (run(), step()). I dettagli sulla selezione delle regole sono in /integrations/backport/configuration/; il gate della CI è in /integrations/backport/production-usage/.

Discovery dei moduli sorgente

La discovery dei sorgenti non è guidata da un manifest. Si basa su una mappa fissa in scripts/merge-sources.php, indicizzata per nome del repository e selezionata in base al target.

Per il target PHP 8.1 la mappa include nextpdf (core), nextpdf-Artisan, nextpdf-compat-legacy, nextpdf-Laravel, nextpdf-Symfony, nextpdf-CodeIgniter e nextpdf-Pro quando Pro è incluso. Per il target PHP 7.4 la mappa si riduce al solo nextpdf. Ogni repository viene risolto come directory di pari livello sotto la radice --source-dir. Ogni repository atteso viene validato prima di qualsiasi copia e, se ne manca uno, il merge viene interrotto riportandone nome e percorso. Verificato su scripts/merge-sources.php (MergeSources::__construct(), run()).

Il merge colloca il core in src/ e ogni adattatore nella relativa sottodirectory con namespace (src/Artisan/, src/Laravel/ e così via). Pro viene collocato in un albero pro/src/ separato, così da poter essere emesso come pacchetto a sé. Verificato su MergeSources (mergeCore(), mergeArtisan(), mergePro()).

Sequenza di boot

1. scripts/build.php viene invocato con la SAPI CLI. Esegue require_once su merge-sources.php e adjust-composer.php.
2. Il punto di ingresso CLI legge le opzioni con getopt() — --version, --source-dir, --output-dir, --target, --dry-run, --no-pro.
3. Viene costruita un’istanza di Build. Il costruttore valida --target rispetto a ['php74', 'php81'] e solleva InvalidArgumentException per un valore non valido prima che inizi qualsiasi lavoro. Per il target PHP 7.4 forza la modalità solo-core e disabilita Pro.
4. Build::run() esegue le cinque fasi e termina con stato 0 in caso di successo, 1 al primo errore.

Verificato su scripts/build.php (punto di ingresso CLI, Build::__construct(), run()).

Binding del container

Non applicabile. Il builder è uno strumento CLI senza container di dependency injection né container dei servizi di un framework. Il collegamento avviene tramite un require_once esplicito, più l’autoloading PSR-4 di Composer di NextPDF\Backport\ (le regole) e NextPDF\Backport\Scripts\ (gli script). Verificato su composer.jsonautoload e sulle istruzioni require_once in scripts/build.php.

Ordine di risoluzione della configurazione

Non esiste un file di configurazione. La configurazione corrisponde all’insieme dei flag CLI, risolti rispetto ai valori predefiniti nello script:

1. Il flag CLI, se fornito.
2. Il valore predefinito nel blocco di parsing di getopt() (ad esempio, il target ha come predefinito php81, la versione 2.0.0).
3. Il comportamento che il costruttore deriva dal target (PHP 7.4 forza la modalità solo-core e nessun Pro, a prescindere da --no-pro).

Verificato su scripts/build.php (punto di ingresso CLI e Build::__construct()). Il riferimento completo dei flag è in /integrations/backport/configuration/.

Diagnostica

L’orchestratore costituisce la propria superficie diagnostica. Eseguire un dry-run (composer build:dry) stampa, senza scrivere nulla, i repository sorgente che verrebbero letti e l’intento di ciascuna fase. Ogni fase stampa un segno di spunta di successo o un errore con nome. Non esiste un sottocomando diagnose separato né un punto di ingresso bin/. Il builder viene invocato tramite scripts/build.php o i suoi alias di Composer-script. Verificato su scripts/build.php (step(), i rami dryRun), scripts/merge-sources.php (il percorso dry-run di run()) e composer.jsonscripts.

Vedi anche

• /integrations/backport/overview/ — che cos’è il builder e che cosa produce.
• /integrations/backport/integration/ — il contratto di integrazione con l’host di build.
• /integrations/backport/configuration/ — le configurazioni di Rector e il riferimento dei flag.
• /integrations/backport/troubleshooting/ — il riferimento agli errori fase per fase.