Boot e descoberta do backport do NextPDF

Ferramenta de build — NÃO é uma dependência de runtime. Esta página explica como o builder é iniciado em um host de mantenedor ou de integração contínua (CI). As aplicações downstream nunca carregam esse código.

Visão geral

O builder não usa framework, container de injeção de dependências nem descoberta automática de service providers. Em vez disso, os scripts de interface de linha de comando (CLI) do PHP são conectados por require_once e pelo autoloader PSR-4 do Composer. Aqui, “descoberta” tem dois sentidos específicos: quais repositórios de origem o estágio de merge lê e como o orquestrador seleciona a configuração do Rector para o alvo.

Visão geral do pipeline de build

O orquestrador é scripts/build.php. Ele inicia o build e executa cinco estágios em sequência. Cada estágio tem um gate; portanto, a primeira falha interrompe o build:

1. Merge das origens — copia os repositórios de origem para uma única árvore.
2. Executar o downgrade do Rector — executa uma passagem para o PHP 8.1; executa duas passagens mais ajustes para o PHP 7.4.
3. Gerar o composer.json — grava o manifesto do pacote gerado com o respectivo mapa replace.
4. Copiar assets estáticos — copia a licença e um changelog gerado.
5. Validar a saída — conta os arquivos PHP emitidos; o gate de sintaxe definitivo é executado depois na CI.

Verificado com base em scripts/build.php (run(), step()). Consulte /integrations/backport/configuration/ para detalhes da seleção de regras e /integrations/backport/production-usage/ para o gate da CI.

Descoberta dos módulos de origem

A descoberta das origens não é orientada por manifesto. scripts/merge-sources.php usa um mapa fixo, indexado pelo nome do repositório e selecionado pelo alvo.

Para o alvo PHP 8.1, o mapa inclui nextpdf (core), nextpdf-Artisan, nextpdf-compat-legacy, nextpdf-Laravel, nextpdf-Symfony, nextpdf-CodeIgniter e nextpdf-Pro quando o Pro está incluído. Para o alvo PHP 7.4, o mapa fica reduzido apenas a nextpdf. O builder resolve cada repositório como um diretório irmão sob a raiz --source-dir. Ele valida cada repositório esperado antes de copiar qualquer coisa. Se algum estiver ausente, o merge é abortado e informa o respectivo nome e caminho. Verificado com base em scripts/merge-sources.php (MergeSources::__construct(), run()).

O merge coloca o core em src/ e cada adaptador sob o respectivo subdiretório com namespace (src/Artisan/, src/Laravel/ e assim por diante). O Pro vai para uma árvore pro/src/ separada, para que o build possa emiti-lo como seu próprio pacote. Verificado com base em MergeSources (mergeCore(), mergeArtisan(), mergePro()).

Sequência de boot

1. scripts/build.php é executado na CLI Server Application Programming Interface (SAPI). Ele faz require_once de merge-sources.php e adjust-composer.php.
2. O ponto de entrada da CLI lê as opções com getopt() — --version, --source-dir, --output-dir, --target, --dry-run, --no-pro.
3. Uma instância de Build é construída. O construtor valida --target em relação a ['php74', 'php81'] e lança InvalidArgumentException para um valor inválido antes que qualquer trabalho comece. Para o alvo PHP 7.4, ele força a saída somente do core e desabilita o Pro.
4. Build::run() executa os cinco estágios e sai com status 0 em caso de sucesso, ou 1 na primeira falha.

Verificado com base em scripts/build.php (ponto de entrada da CLI, Build::__construct(), run()).

Bindings do container

Não se aplica. O builder é uma ferramenta de CLI. Ele não tem container de injeção de dependências nem container de serviços de framework. A ligação é feita por chamadas explícitas de require_once, além do autoloading PSR-4 do Composer de NextPDF\Backport\ (regras) e NextPDF\Backport\Scripts\ (scripts). Verificado com base em composer.jsonautoload e nas instruções require_once em scripts/build.php.

Ordem de resolução da configuração

Não há arquivo de configuração. A configuração vem de flags de CLI resolvidas em relação aos padrões embutidos no script:

1. A flag de CLI, se fornecida.
2. O padrão no bloco de parsing do getopt() (por exemplo, o alvo padrão é php81 e a versão padrão é 2.0.0).
3. O comportamento que o construtor deriva do alvo (o PHP 7.4 força somente o core e sem Pro, independentemente de --no-pro).

Verificado com base em scripts/build.php (ponto de entrada da CLI e Build::__construct()). A referência completa das flags está em /integrations/backport/configuration/.

Diagnóstico

O orquestrador oferece seu próprio diagnóstico. Execute um dry run (composer build:dry) para imprimir os repositórios de origem que seriam lidos e a intenção de cada estágio, sem gravar nada. Cada estágio imprime um indicador de sucesso ou uma falha identificada por nome. Não há subcomando de diagnóstico separado nem ponto de entrada bin/. O builder é executado por meio de scripts/build.php ou dos aliases correspondentes de Composer-script. Verificado com base em scripts/build.php (step(), as ramificações dryRun), scripts/merge-sources.php (o caminho de dry run do run()) e composer.jsonscripts.

Veja também

• /integrations/backport/overview/ — o que é o builder e o que ele produz.
• /integrations/backport/integration/ — o contrato de integração do build-host.
• /integrations/backport/configuration/ — configurações do Rector e a referência das flags.
• /integrations/backport/troubleshooting/ — referência de falhas estágio por estágio.