Pdf Bundle Laravel Package

Technical Evaluation

Architecture fit. There is a fundamental mismatch to surface before any code review: fbeen/pdf-bundle is a Symfony bundle, not a Laravel package. Bundles depend on Symfony\Component\HttpKernel\Bundle\Bundle, container Extension classes, and the Symfony config-tree/DI compiler pass pipeline. Laravel ships Symfony components (HttpFoundation, Console, Routing) but has no bundle registry and no DI extension compilation, so this package cannot be installed into a Laravel service provider as-is. The only portable asset is the wrapped upstream library (psliwa/php-pdf), which is plain PHP and Composer-installable without the bundle.

Integration feasibility. The bundle's entire stated value proposition is "same as psliwa/pdf-bundle but works with Symfony 3.3" — i.e., it is a compatibility patch fork, not a feature fork. For a Laravel codebase, that value is zero. Realistic options, in order of preference:

1. Wrap the underlying library directly behind our own PdfRenderer interface (no bundle, no fork).
2. Adopt a maintained Laravel-native renderer (dompdf, mPDF, Snappy/wkhtmltopdf, Browsershot) and treat this package as a rejected spike.
3. Ignore the package entirely and consume only psliwa/php-pdf if output fidelity requirements specifically match it.

Technical risk.

• Zero stars, zero dependents, single-maintainer fork — no community validation, no downstream bug surface, no discoverable security disclosure path, no CVE coverage. Supply-chain review will flag it.
• Fork drift. If upstream psliwa/php-pdf or the bundle fixes a security or correctness issue, this fork has no obligation to track it. We inherit a private maintenance burden on day one.
• Stack rot. Targeting Symfony 3.3 (EOL early 2019) implies PHP 5.x/7.0-era constraints. It will not install on PHP 8.2+ without patching, which blocks our runtime upgrade path.
• MIT license is clean — the only low-risk dimension here.

Key questions.

• What is the actual business requirement — HTML-to-PDF fidelity, Unicode/CJK, digital signatures, PDF merging, or performance? The answer likely eliminates this package outright.
• Is there a legacy Symfony 3.3 application in the estate, or is "Symfony 3.3" a leftover from a copy-pasted description?
• Does the underlying library pass our PHP 8.x compatibility check, and what is its own last-release date?
• Who owns patching this if upstream abandons it (already effectively abandoned at this fork's baseline)?
• What drove the original fork — a one-line composer constraint, or real behavioral changes we would need to audit?
• Does it survive a dependency vulnerability scan and license/SBOM policy?

Integration Approach

Stack fit. Poor for Laravel. A TPM should treat this as "not a fit for the target platform" and redirect the evaluation to the underlying library or a Laravel-native alternative. Do not spend engineering cycles building a bundle-shim — that is custom infrastructure for a zero-adoption fork.

Migration path. If an existing service already uses psliwa/pdf-bundle on Symfony 3.3, this fork is a legitimate stopgap to unblock a Composer resolution — nothing more. Treat it as technical debt with a scheduled exit. If the goal is greenfield PDF generation in Laravel, there is no migration path from this package; there is only a fresh selection decision.

Compatibility. Verify before anything else: PHP constraint in composer.json, psliwa/php-pdf version pinned, presence of a DependencyInjection/ extension and Resources/config/services.yml (confirms it is bundle-only glue), and whether the renderer supports the fonts/scripts our documents require. A 30-minute read of the repo settles it.

Sequencing.

1. Requirements capture: document types, volume, fidelity bar, latency budget.
2. Compatibility probe: attempt install against our PHP/Laravel versions in a throwaway container.
3. Fidelity spike: render three representative documents (largest, most complex layout, non-Latin text) and compare to current output.
4. Vendor/reject decision with a written exit strategy if vendored.
5. If rejected, re-run selection against two maintained alternatives and document the comparison for audit.

Operational Impact

Maintenance. High for a small payoff. A zero-dependent fork means we are the de facto maintainer: no upstream patches, no issue triage, no release cadence. Budget for at least a periodic compatibility patch at every PHP upgrade, and for owning the SBOM entry indefinitely.

Support. No documentation beyond the upstream bundle's, no community to ask, no vendor relationship. Internal runbook and a named owner are prerequisites to adoption, not nice-to-haves.

Scaling. PDF rendering is CPU- and memory-bound; a pure-PHP renderer scales worse than a headless-Chrome or wkhtmltopdf sidecar. Any adoption must be async — push rendering to a queue worker with an explicit memory ceiling and timeout, write output to object storage, and return a signed URL. Never render inline in a request path. Large documents are the classic failure mode here.

Failure modes.

• Memory exhaustion on multi-page or image-heavy documents (PHP renderers are notoriously hungry).
• Font/Unicode gaps producing silent glyph substitution or blank output in non-Latin scripts.
• Request timeouts if rendering is left synchronous.
• Composer resolution failures after any PHP runtime bump, blocking unrelated deploys.
• Fork abandonment with no patch path for a discovered vulnerability.

Ramp-up. Low individual learning curve — the API surface is small and the bundle is thin glue — but the organizational ramp-up is the cost: security review, SBOM registration, ownership assignment, and an exit plan. For a zero-star fork with zero dependents and a one-line raison d'être, the expected value is negative for a Laravel target. Recommendation: reject for integration; retain as a reference point only if a legacy Symfony 3.3 application requires the stopgap.