Pdf Bundle Laravel Package

Technical Evaluation

Architecture fit. The framing in the brief is misleading in a way a TPM must correct before any planning happens: orkestra/pdf-bundle is a Symfony bundle, not a Laravel package. It offers a PdfManager that hands back a configured engine adapter, with pluggable backends (wkhtmltopdf, TCPDF, Zend\Pdf), centralized page-size/orientation config, and Twig/HTML → PDF rendering usable from controllers, commands, and background jobs. The architectural idea — one uniform rendering contract over swappable engines — is exactly the shape a document-generation capability should have. The implementation, however, is welded to Symfony's DI container, bundle registration lifecycle, and configuration tree. In a Laravel app there is no service provider, no publishable config, no facade, no auto-discovery. The value on offer is the pattern; the artifact is not installable value.

Integration feasibility. Low. Composer will pull the code down, but nothing wires up without glue we write and own: a ServiceProvider to register the bundle's services, a mapper from config/pdf.php into the bundle's expected array shape, and an adapter exposing the renderer behind a contract we control. That is real work for a package with 2 stars, 0 dependents, and a composite score of 0.17 — no install base for examples, no StackOverflow corpus, no third-party fixes for the Laravel path, no one to ask.

Technical risk. High, and concentrated in the backends rather than the wrapper:

• wkhtmltopdf is effectively unmaintained upstream, Qt-WebKit-based, with no modern CSS support (flexbox, grid, web fonts unreliable) and routine breakage on modern base images over fonts, sandboxing, and OpenSSL.
• Zend\Pdf is a dead namespace (ZF2 → Laminas migration); Composer will resolve an abandoned package or fail on PHP 8 constraints, and risks autoload collisions alongside Laminas packages.
• TCPDF is legacy-maintained with a large memory footprint and its own HTML/CSS subset.
• Shelling out to a binary is an inherited security and reliability surface — argument injection, timeouts, orphaned child processes.
• With two of three backends legacy, the "uniform API" delivers the illusion of portability: swapping engines changes fidelity, pagination, and CSS support in ways the abstraction does not normalize.

Key questions before commitment:

1. What PHP/Symfony versions does the current tag actually support, and does it install cleanly on PHP 8.2/8.3?
2. Is the repo receiving security or compatibility commits, or is it frozen?
3. Which backends do we actually need? If the answer is one, the abstraction is dead weight.
4. What are the real document requirements — HTML fidelity, headers/footers, PDF/A, digital signatures, form fields, CJK fonts? Legacy engines fail several of these.
5. Who internally owns a fork? With zero dependents, fork-and-patch is the only viable support model.

Integration Approach

Stack fit. Poor for Laravel. Tolerable only in a legacy Symfony 2/3 application already running Zend\Pdf or wkhtmltopdf in production. For a greenfield Laravel service the fit is negative — we would spend more effort containing the package than it saves.

Migration path. Two routes, both ending at a contract we own:

• Contain and abstract: define a PdfRenderer contract in the application layer (render(html, options) → bytes), implement it with an adapter around this bundle, and treat the bundle as an interchangeable detail. Preserves optionality; call sites never see the package.
• Bypass (recommended default): implement the same contract directly against a maintained backend — spatie/laravel-pdf (headless Chromium), barryvdh/laravel-dompdf, or knplabs/knp-snappy if wkhtmltopdf is a hard constraint. Roughly a day of work, and it removes a dependency we cannot get support for.

Compatibility. Expect friction on three axes simultaneously: PHP version (typed properties; TCPDF/Zend deprecations), Symfony major version (bundle extension and DI semantics changed materially across 3/4/5/6), and the pinned wkhtmltopdf binary per environment. Any one drifting breaks the others.

Sequencing.

1. Spike (1–2 days): install in a scratch app, wire a minimal provider, render one representative document per backend. Surfaces incompatibilities cheaply.
2. Decide: if clean and one backend meets requirements, wrap it behind our contract; if not, adopt a maintained alternative under the same contract.
3. Abstract first: land the PdfRenderer interface plus a fake implementation so later integration is a swap, not a refactor.
4. Pilot one low-risk document type behind a feature flag.
5. Broaden only after the fallback path has been exercised in staging.

Roadmap framing. This enables document output as a first-class roadmap capability — invoices, statements, contracts, packing slips, compliance certificates, receipts, report exports — and makes the build-vs-buy call explicit: self-hosted rendering vs. $0.01–$0.10 per document SaaS (DocRaptor, Prince, Adobe PDF Services). It also supports data-residency and on-prem commitments where documents cannot leave the customer network, and lets us A/B the same template across engines to price the fidelity/portability trade-off.

Operational Impact

Maintenance. We inherit the package. With 2 stars and 0 dependents there is no upstream community absorbing CVE fixes, PHP upgrades, or Symfony compatibility work. Budget a named maintainer and a fork-and-patch posture from day one — treating this as a normal Composer dependency is the single most likely failure mode.

Support. No vendor, no active issue triage, no documented upgrade path. Knowledge concentrates in whoever runs the spike — bus factor of one unless deliberately spread.

Scaling. The usable backends scale poorly and asymmetrically. wkhtmltopdf is CPU- and memory-heavy, spawns a process per document (tens to hundreds of MB RSS each), and needs a worker pool with concurrency caps; it does not tolerate bursty synchronous use inside a web request. TCPDF runs in-process, making PHP memory_limit and request timeouts the ceiling. Neither is queue-aware — we own batching, retries, and backpressure. Plan to move all generation off the request path.

Failure modes to instrument explicitly:

• Binary missing, non-executable, or wrong version on a rebuilt container image.
• Silent hangs and orphaned child processes from wkhtmltopdf on malformed HTML or remote asset fetches.
• Font/glyph gaps producing blank or tofu output — a correctness failure that looks like success.
• Memory exhaustion and fatals on large TCPDF documents.
• Autoload collisions from the abandoned Zend namespace alongside Laminas.
• Output drift between backends after any "swap," breaking golden-file tests.

Ramp-up. The public API is learnable in a day; the debugging surface is not. Engineers will burn disproportionate time on environment-specific binary issues and on reverse-engineering undocumented backend behavior. Plan a half-day onboarding plus a written runbook covering binary provisioning, queue configuration, and known failure signatures — otherwise each new engineer rediscovers the same failures.

Recommendation. Do not adopt as a strategic dependency. Use it as a throwaway spike to validate requirements, then default to a maintained Laravel-native renderer behind an internally owned PdfRenderer contract. To executives: the strategic value is the architecture, not the code — one internal interface, several engines behind it — and the ~200 lines are ours to own. The 0.17 score and 0-dependent profile accurately reflect the operational burden this package would transfer onto us.