Amorçage et découverte d'Artisan dans NextPDF
Artisan est une bibliothèque PSR-4 simple, sans service provider, sans bundle et sans manifeste d’auto-découverte côté framework. Elle « démarre » dès que ses classes peuvent être chargées par l’autoloader ; la découverte se limite au mapping PSR-4 de Composer, rien de plus.
Comment fonctionne la découverte
Section intitulée « Comment fonctionne la découverte »Le package composer.json déclare deux racines PSR-4 — NextPDF\Artisan\ → src/Artisan/ et NextPDF\Parser\ → src/Parser/. Il n’y a pas de extra.laravel, pas de classe de bundle Symfony et pas de registrar CodeIgniter. Rien n’inspecte, n’enregistre ni ne se greffe au démarrage.
Le point d’intégration se trouve du côté de nextpdf/core. Document (via le concern HasTextOutput) expose writeHtmlChrome(), qui effectue à l’exécution une vérification class_exists() pour NextPDF\Parser\PdfReader et NextPDF\Artisan\PageImporter. Quand les deux se résolvent via l’autoloader, le chemin Chrome est disponible. Dans le cas contraire, core lève une exception de mise en page au lieu de laisser survenir une erreur fatale. La « découverte » revient donc à ceci : les classes Artisan sont-elles présentes dans l’autoloader ? Composer répond à cette question — aucune mécanique de framework n’est impliquée.
C’est un choix de conception délibéré. Le pont est une capacité que le moteur core atteint à travers une frontière de package, pas un service géré par un framework. Artisan reste ainsi utilisable de la même manière dans Laravel, Symfony, CodeIgniter, un script CLI ou un worker de file d’attente, car aucun d’eux n’est requis.
Séquence de démarrage
Section intitulée « Séquence de démarrage »Il n’y a pas de kernel d’amorçage, pas d’enregistrement de commande et pas de phase de provider différé. Le premier appel à writeHtmlChrome() constitue à lui seul le point d’entrée du cycle de vie.
Liaisons du conteneur
Section intitulée « Liaisons du conteneur »Artisan n’a pas de conteneur d’injection de dépendances et n’enregistre aucune liaison. Les composants sont de simples objets injectés par le constructeur : construis un ChromeRendererConfig, passe-le à ChromeHtmlRenderer, et injecte éventuellement un logger PSR-3 et un HtmlSecurityPolicyInterface personnalisé. Dans un conteneur hôte, enregistre ChromeHtmlRenderer toi-même comme singleton — voir l’exemple sur /integrations/artisan/production-usage/.
Résolution des services sans conteneur
Section intitulée « Résolution des services sans conteneur »Certaines capacités de NextPDF (les contrats de facture électronique Premium) sont normalement résolues via un conteneur de framework. Artisan s’exécute aussi dans des environnements sans conteneur — outils CLI, scripts autonomes, runners personnalisés — et fournit donc EInvoiceServiceFactory :
| Méthode | Renvoie | Quand null |
|---|---|---|
makeEmbedder() | EmbedderInterface (Pro) | Niveau Pro non installé |
makeValidator() | ValidatorInterface (Enterprise) | Niveau Enterprise non installé |
makeDefaultProfile() | ProfileInterface (EN16931, Pro) | Niveau Pro non installé |
makeSchematronRunner() | SchematronRunnerInterface (Enterprise) | Niveau Enterprise non installé |
Chaque appel renvoie une instance fraîche (sémantique à usage unique — les appels d’incorporation et de validation possèdent un contexte d’analyse XML mutable et ne doivent pas partager d’état). La factory est une aide pratique pour le rare cas sans conteneur, pas un service locator. Le modèle privilégié reste d’assembler les objets au moment de la construction et de les passer comme arguments du constructeur. Le comportement de retour null en l’absence du composant reflète les packages wrapper de framework, si bien que le même code appelant s’exécute avec ou sans Premium. Source : src/Artisan/EInvoiceServiceFactory.php ; testé en intégration dans tests/Integration/Artisan/EInvoiceServiceFactoryIntegrationTest.php.
Ordre de résolution de la configuration
Section intitulée « Ordre de résolution de la configuration »Il n’y a pas de cascade de fichiers de configuration. La configuration correspond à ce que tu passes à ChromeRendererConfig :
- Des arguments de constructeur explicites, ou
ChromeRendererConfig::fromArray()à partir d’un tableau fourni par l’hôte (clés en snake-case ; les clés non définies se rabattent sur les valeurs par défaut du constructeur ;chrome_binaryn’est appliqué que lorsque c’est une chaîne non vide).
La configuration résolue est immuable pendant toute la durée de vie du renderer. Voir /integrations/artisan/configuration/ pour chaque clé.
Diagnostics
Section intitulée « Diagnostics »- « Le pont est-il découvrable ? » — si
class_exists(\NextPDF\Artisan\PageImporter::class)vauttrue, la classe est présente dans l’autoloader de Composer ; core utilisera le chemin Chrome. - « A-t-il démarré ? » — il n’y a pas de démarrage susceptible d’échouer ; une dépendance manquante apparaît au premier appel à
writeHtmlChrome()sous la forme d’une exception typée, documentée sur /integrations/artisan/troubleshooting/. - Vérification Premium sans conteneur —
EInvoiceServiceFactory::makeEmbedder() === nullsignifie que le niveau Pro n’est pas installé ; le chemin de rendu open-source n’est pas affecté.
Voir aussi
Section intitulée « Voir aussi »- /integrations/artisan/integration/
- /integrations/artisan/overview/
- /integrations/artisan/configuration/
- /integrations/artisan/production-usage/
- /integrations/artisan/troubleshooting/