Dompdf Bundle Laravel Package

Technical Evaluation

Architecture fit: the package is the wrong framework, and that is the first finding. slik/dompdf-bundle is a Symfony 2 bundle — its contributions are a Bundle subclass, a DI extension reading a slik_dompdf config tree, and service-container wiring that exposes Dompdf via $container->get('slik_dompdf'). Laravel has no bundle/kernel-bundle concept, so none of that code is loadable or adaptable. The reusable asset is dompdf/dompdf itself, which is available directly and at a far newer major version. Net transferable value to a Laravel estate is approximately zero: we would be reading this package as documentation, not adopting it as a dependency.

Integration feasibility: possible only as a rewrite, and the rewrite is dominated. We could read the bundle's config schema and hand-write a Laravel service provider registering a singleton Dompdf with equivalent options — roughly half a day. That yields a bespoke internal wrapper with no upstream, no tests, and no version guarantees, and it is strictly worse than barryvdh/laravel-dompdf (maintained, thousands of dependents) or dompdf/dompdf ^3 used directly behind ~30 lines of our own binding.

Technical risk: high, and concentrated in the transitive dependency chain. Symfony 2.x reached end-of-maintenance in November 2018. The bundle's constraints will pin PHP to the 5.x/7.0–7.1 era and Symfony to ~2.3|~2.7, which in turn pins an old dompdf release. Multiple advisories exist against pre-2.x dompdf (local file disclosure via resource handling, phar deserialization, remote-resource/SSRF behavior). Installing this into a modern Laravel application either fails Composer resolution outright or requires --ignore-platform-reqs plus a knowingly unpatched PDF engine in the request path — unacceptable for anything rendering user-supplied HTML.

Signal quality is the decisive datapoint. 9 stars, 0 dependents, composite score 3.03. Zero dependents means no production usage evidence, no issue history to mine, and no realistic expectation that a security report would be answered. We would be the only operator of this code in the wild.

Key questions for the requester

1. Is the requirement "HTML→PDF in Laravel," or specifically "reproduce this bundle's configuration and output" (i.e., matching a legacy Symfony service byte-for-byte or visually)?
2. Which dompdf version does the source system pin, and do we have golden rendered-document fixtures we must match?
3. Is the source system being migrated from Symfony 2? If so, the port target is the configuration and the templates — not the bundle.
4. Which features are actually in use: custom fonts, remote images, headers/footers, encryption, page numbering, PDF/A?
5. Is headless-Chrome rendering acceptable (spatie/laravel-pdf, Browsershot)? It handles modern CSS far better than any dompdf generation and removes the library from the trust boundary.

Integration Approach

Stack fit — replace, do not adapt. Ranked options for a Laravel target:

Migration path: treat the bundle as a specification, not a dependency. Extract the slik_dompdf configuration keys the legacy app actually sets — orientation, default paper size, enable_remote, font_dir, temp_dir, base path, DPI, font cache — plus any custom fonts committed to the repo. Re-create those as config/pdf.php and a single PdfRenderer service wrapping whichever engine we choose. Application code depends on that interface, never on Dompdf directly. That is the one durable design decision here, and it preserves the option to swap engines later without touching call sites.

Compatibility. Target PHP 8.2/8.3 on the current Laravel LTS. Before anything else, verify there is no hard transitive symfony/* constraint conflict. If some legacy shared package genuinely requires this bundle, isolate it behind a separate internal rendering service rather than pulling Symfony 2 into the main application.

Sequencing

1. Confirm the requirement is rendered output, not package reuse (question 1).
2. Harvest 10–20 representative production documents and render them with the legacy system as golden fixtures.
3. Stand up the replacement engine on a branch and render the same fixtures.
4. Diff on page count, extracted text, and visual comparison. Font registration and table pagination are where version drift — and dompdf→Chromium drift — will surface.
5. Resolve deltas; expect most of the effort to land in font setup and page-break CSS.
6. Ship behind PdfRenderer with a feature flag for one release cycle.
7. Archive the bundle reference and record why it was not adopted, so the question does not reopen.

Operational Impact

Maintenance. Effectively zero upstream. With 0 dependents and 9 stars, any defect becomes ours and the fix lives in a private fork — a permanent undocumented liability for a capability that is a solved problem elsewhere. This is the clearest argument for skipping the intermediate step entirely.

Support. No vendor, no community, no CVE feed. If an advisory lands against the pinned dompdf version, we cannot patch without first unpinning the Symfony 2 constraint, which cascades into a full replacement anyway. Better to pay that cost once, now, deliberately.

Scaling. The bundle contributes nothing to throughput — it is container registration. Engine characteristics apply regardless: dompdf is CPU- and memory-bound and single-threaded per render. Plan a dedicated pdf queue, memory_limit of 512M or higher for large tables, and an explicit 30–60s render timeout so a pathological document cannot pin a worker. Chromium rendering is heavier per process but faster on complex CSS; both want horizontal worker scaling, not vertical. Cache rendered PDFs keyed on a hash of input + template + config version — invoice-style documents are immutable once issued.

Failure modes to instrument

• Memory exhaustion on long tables or deeply nested markup — the most common dompdf production incident; emit a peak-memory-per-render metric.
• Remote asset fetch (SSRF) when enable_remote/isRemoteEnabled is on and user HTML is rendered — treat as a security control, not a config toggle: disable, or allowlist hosts and pre-inline assets.
• Font resolution failure producing silent fallback glyphs — assert expected fonts in CI with a fixture test.
• Timeout/hang on malformed HTML — enforce worker-level timeouts and alarm on queue latency.
• Output drift after any engine or font change — keep the golden fixtures in CI as a regression gate.

Ramp-up. Low for engineering: whoever picks this up needs roughly half a day to validate layout fidelity against a real template (an actual invoice, not a hello-world) and a day to wire the interface, queue job, and artifact storage. The larger cost is organisational — establishing the queue-based pattern and the renderer abstraction so that "PDF export" is treated as a thin, swappable adapter rather than an architectural component.