Dompdf Bundle Laravel Package

Technical Evaluation

Verdict: there is nothing here to integrate into a Laravel application. The leverage is conceptual, not literal. A TPM should treat this package as a reference implementation of a requirement, not a dependency candidate.

Architecture fit es/dompdf-bundle is a Symfony 2 bundle. It boots via AppKernel::registerBundles(), reads a YAML config tree (es_dompdf.defaults), and exposes a container service retrieved with $this->get('dompdf'). Laravel has no kernel-bundle lifecycle, no bundle config loader, and no equivalent container retrieval idiom in controllers. The package is not merely untested against Laravel — it has no attachment point. Any adoption attempt fails at bootstrap, before code quality is even a question.

Stripping the framework wiring, the package's entire contribution is: (1) register Dompdf\Dompdf in a DI container, (2) pass a config array through to its constructor, (3) wrap two calls — streamHtml($html, $filename) and getPdf($html). In Laravel that is a service provider, a published config file, and about twenty lines of adapter. The architectural fit is therefore zero on the package, positive on the interface it documents.

Integration feasibility: not feasible, and not worth forcing Last release 2017-02-14; 0 stars; 0 dependents; single author; no issue or CI evidence. Its composer.json will pin Symfony ~2.x and a dompdf/dompdf from the same era. Modern Laravel requires Symfony 6/7 components and PHP 8.1+. Dependency resolution fails outright; the only install path is --ignore-platform-reqs plus hand-edited constraints, which is disqualifying for anything that reaches production. Symfony 2 reached end-of-life in November 2018, so it would also drag an EOL framework generation into the graph transitively.

Technical risk: high and already realized

• Security. Unmaintained since 2017 means no CVE response. HTML→PDF is an injection surface: dompdf has a documented advisory history around remote resource fetching, chroot escape, and local file inclusion. The bundled version predates years of hardening.
• Supply chain. composer audit will flag it and block CI. Zero dependents means no one has validated an upgrade path; we would be the first to discover the breakage, and the only ones able to fix it.
• Abandonment is a fact, not a forecast. Budget for owning it, or don't take it.

Key questions for the requester

1. Is the requirement "use es/dompdf-bundle," or "generate PDFs from HTML in our Laravel app"? If the latter, this is almost certainly a search-result artifact and the conversation shifts to renderer choice.
2. What are the target PHP and Laravel versions? On PHP 8.x this is a non-starter and the discussion ends.
3. What fidelity is required — text-heavy invoices, or pixel-accurate brand templates with flexbox/grid and web fonts? dompdf renders a limited CSS 2.1 subset; that determines whether the underlying engine is even right.
4. Is there an existing Symfony 2 app this was written for, making the real task a Symfony→Laravel migration rather than a greenfield build?
5. What volume, and is synchronous in-request rendering acceptable? dompdf costs hundreds of milliseconds to seconds per document.
6. Who is the named owner for PDF rendering long term?

Integration Approach

Stack fit: none. Replace, do not port. Reframe the decision as renderer selection first, wrapper second — keep those two choices separable in the design so we are not locked to one engine.

• barryvdh/laravel-dompdf — the maintained Laravel wrapper for the same underlying engine and the direct functional equivalent of this bundle: service provider, facade, publishable config, loadHTML()->stream()/download()/output(). If the requirement truly is "dompdf in Laravel," this is the same-day swap.
• dompdf/dompdf bound directly in a service provider — if we want zero wrapper risk. The es/dompdf-bundle README is effectively the spec for this: bind a singleton, map dpi, defaultPaperSize, defaultFont, chroot, isRemoteEnabled, isHtml5ParserEnabled into the options array.
• spatie/browsershot (headless Chromium) — if the driver is visual fidelity rather than engine loyalty. Higher fidelity; adds a binary and a process-spawn dependency to the runtime image.

Migration path — only relevant if we are porting an existing Symfony 2 consumer:

1. Register a DompdfServiceProvider binding the renderer under the same dompdf container key.
2. Port the YAML defaults block to config/dompdf.php with a one-to-one option mapping.
3. Write a thin adapter exposing the identical streamHtml() / getPdf() signatures so call sites are untouched — this keeps the port mechanical and reviewable, roughly 1–2 days including tests.
4. Swap the adapter internals to the chosen wrapper afterward, so the port and the upgrade are separately revertible changes.

Compatibility Never place the original bundle in the application's composer.json. If a stakeholder insists on evaluating it, isolate it in a throwaway container — its 2017-era transitive constraints will fight the rest of the lockfile. The MIT license imposes no legal constraint on either path.

Sequencing Renderer decision → owner assignment → adapter contract (the two methods plus the config keys, lifted verbatim from this README) → service provider + config → fidelity spike against real templates → swap internals to the maintained wrapper → queue offloading if volume demands it. The first three steps cost days; everything after is engineering execution.

Operational Impact

Maintenance The package itself contributes zero maintenance burden because it will never be installed. The real obligation is dompdf/dompdf and its CVE stream — that is where the rendering and the risk live, and it must be pinned and monitored regardless of which wrapper fronts it. Adopting the bundle instead would convert a routine dependency-update task into open-ended ownership of someone else's 2017 code.

Support No upstream triage, no issue activity, no author responsiveness. Internal support means: an on-call engineer reads dompdf source when a document renders wrong. This is acceptable for a small surface (two methods, an options pass-through) and unacceptable as an unknown in a stack trace at 2 a.m. The mitigation is a single named owner and a thin adapter that makes the engine replaceable.

Scaling Pure-PHP rendering with no external binary is an asset for air-gapped and regulated environments, and a liability for throughput. Per-document cost of hundreds of milliseconds to several seconds, plus memory proportional to document complexity, makes synchronous in-request generation a tail-latency and worker-saturation problem at volume. Design the adapter so generation can move behind a queue without touching call sites; batch and report workloads should never render in the request path.

Failure modes

• Fidelity drift — templates look right in a browser and wrong in the PDF (flexbox, grid, web fonts, running headers). Mitigate with a golden-template test suite before rollout, not after.
• Injection — user-influenced HTML reaching the renderer, especially with isRemoteEnabled on. Default it off and constrain chroot; treat the renderer as untrusted-input-adjacent.
• Silent upstream breakage — a PHP minor bump or a transitive update changes output. Pin, test, and treat renderer upgrades as reviewed changes.
• EOL drift — the temptation to "just add the bundle" pulls a dead framework generation into the graph. Explicitly foreclose this in the design doc.

Ramp-up Low for any Laravel engineer: one service provider, one adapter class, one config file, two methods. Expect half a day to a working spike and 1–2 days to tested, queued, monitored production output. The cost of the wrong choice here is not learning curve — it is a multi-quarter argument about why an abandoned Symfony 2 bundle is in a Laravel lockfile.

The one-line decision: adopt dompdf (or a maintained Laravel wrapper) as the renderer; skip this package. It buys twenty minutes of wiring and costs a maintenance obligation on code nobody else uses.