Arranque y descubrimiento del backport de NextPDF

Herramientas de compilación: NO son dependencias de tiempo de ejecución. Este documento describe cómo se inicializa el compilador en un host de un mantenedor o de CI. Las aplicaciones derivadas nunca cargan este código.

De un vistazo

El compilador no usa framework, contenedor de inyección de dependencias ni descubrimiento automático de proveedores de servicios. Es un conjunto de scripts PHP de CLI conectados mediante require_once y el autocargador PSR-4 de Composer. Aquí, «descubrimiento» significa dos cosas concretas: qué repositorios de origen lee la etapa de fusión y cómo selecciona el orquestador la configuración de Rector para el destino.

Descripción general de la canalización de compilación

El orquestador es scripts/build.php. Se inicia y, a continuación, ejecuta cinco etapas ordenadas. Cada etapa está controlada por una compuerta, de modo que el primer fallo detiene la compilación:

1. Fusionar orígenes — copiar los repositorios de origen en un único árbol.
2. Ejecutar la rebaja de versión con Rector — una sola pasada para PHP 8.1; dos pasadas, más correcciones, para PHP 7.4.
3. Generar composer.json — escribir el manifiesto del paquete producido con su mapa replace.
4. Copiar recursos estáticos — la licencia y un registro de cambios generado.
5. Validar la salida — contar los archivos PHP emitidos; la compuerta de sintaxis de referencia se ejecuta más adelante en CI.

Verificado contra scripts/build.php (run(), step()). Los detalles de la selección de reglas están en /integrations/backport/configuration/; la compuerta de CI está en /integrations/backport/production-usage/.

Descubrimiento de los módulos de origen

El descubrimiento de orígenes no se basa en un manifiesto. Consiste en un mapa fijo en scripts/merge-sources.php, indexado por el nombre del repositorio y seleccionado por el destino.

Para el destino PHP 8.1, el mapa incluye nextpdf (núcleo), nextpdf-Artisan, nextpdf-compat-legacy, nextpdf-Laravel, nextpdf-Symfony, nextpdf-CodeIgniter y nextpdf-Pro cuando se incluye Pro. Para el destino PHP 7.4, el mapa se reduce únicamente a nextpdf. Cada repositorio se resuelve como un directorio hermano bajo la raíz --source-dir. Cada repositorio esperado se valida antes de cualquier copia y, si falta alguno, se aborta la fusión indicando su nombre y su ruta. Verificado contra scripts/merge-sources.php (MergeSources::__construct(), run()).

La fusión coloca el núcleo en src/ y cada adaptador bajo su subdirectorio con espacio de nombres (src/Artisan/, src/Laravel/, y así sucesivamente). Pro se coloca en un árbol pro/src/ independiente para que pueda emitirse como su propio paquete. Verificado contra MergeSources (mergeCore(), mergeArtisan(), mergePro()).

Secuencia de arranque

1. scripts/build.php se invoca bajo la SAPI de CLI. Carga merge-sources.php y adjust-composer.php mediante require_once.
2. El punto de entrada de CLI lee las opciones con getopt() — --version, --source-dir, --output-dir, --target, --dry-run, --no-pro.
3. Se construye una instancia de Build. El constructor valida --target contra ['php74', 'php81'] y lanza InvalidArgumentException ante un valor no válido antes de iniciar cualquier trabajo. Para el destino PHP 7.4, fuerza solo el núcleo y desactiva Pro.
4. Build::run() ejecuta las cinco etapas y finaliza con el estado 0 en caso de éxito y 1 ante el primer fallo.

Verificado contra scripts/build.php (punto de entrada de CLI, Build::__construct(), run()).

Vinculaciones del contenedor

No aplicable. El compilador es una herramienta de CLI sin contenedor de inyección de dependencias ni contenedor de servicios de framework. El cableado se hace con un require_once explícito, además de la autocarga PSR-4 de Composer de NextPDF\Backport\ (reglas) y NextPDF\Backport\Scripts\ (scripts). Verificado contra composer.jsonautoload y las instrucciones require_once en scripts/build.php.

Orden de resolución de la configuración

No existe ningún archivo de configuración. La configuración es el conjunto de marcas de CLI, resuelto a partir de los valores predeterminados incorporados en el script:

1. La marca de CLI, si se proporciona.
2. El valor predeterminado del bloque de análisis de getopt() (por ejemplo, el destino predeterminado es php81 y la versión predeterminada es 2.0.0).
3. El comportamiento que el constructor deriva del destino (PHP 7.4 fuerza solo el núcleo y desactiva Pro, con independencia de --no-pro).

Verificado contra scripts/build.php (punto de entrada de CLI y Build::__construct()). La referencia completa de las marcas está en /integrations/backport/configuration/.

Diagnósticos

El orquestador es su propia superficie de diagnóstico. Ejecutar una pasada en seco (composer build:dry) permite imprimir, sin escribir nada, los repositorios de origen que se leerían y la operación prevista en cada etapa. Cada etapa imprime una marca de éxito o un fallo identificado por nombre. No hay un subcomando de diagnóstico independiente ni un punto de entrada bin/. El compilador se invoca a través de scripts/build.php o de sus alias de script de Composer. Verificado contra scripts/build.php (step(), las ramas dryRun), scripts/merge-sources.php (la ruta de ejecución en seco de run()) y composer.jsonscripts.

Véase también

• /integrations/backport/overview/ — qué es el compilador y qué produce.
• /integrations/backport/integration/ — el contrato de integración del host de compilación.
• /integrations/backport/configuration/ — las configuraciones de Rector y la referencia de marcas.
• /integrations/backport/troubleshooting/ — referencia de fallos por etapa.