Dompdf Bundle Laravel Package

Product Decisions This Supports

The decision this actually informs is the renderer, not this package. es/dompdf-bundle is a ~50-line Symfony 2 service wrapper around dompdf/dompdf. A PM should pull the decision up a level: do we ship HTML→PDF export, and which engine renders it? This package only ever answers "how do we wire dompdf into Symfony 2," which is a question a Laravel team never asks.

Feature scope it legitimizes (and caps). The entire surface is two calls — streamHtml($html, $filename) for browser delivery and getPdf($html) for raw bytes. That maps cleanly onto a roadmap item like "download invoice as PDF" or "email a statement," and equally cleanly tells you what you don't get: no queued batch generation, no templating layer, no storage abstraction, no signing, no accessibility tagging. If a stakeholder's mental model of "PDF support" exceeds stream-and-bytes, that gap is a scoping conversation, not a package evaluation.

Build vs. buy vs. wire-up-yourself — and the honest answer is "wire it up." There is no "buy" here; the license is MIT and the price is zero, but the value added over composer require dompdf/dompdf is container registration plus a config passthrough (es_dompdf.defaults → dpi, defaultPaperSize, and friends). In Laravel that is a service provider and a config file — an afternoon, not a sprint. Frame the build/buy call against dompdf the engine (mature, maintained, pure-PHP, no system binaries) and treat the wrapper as a disposable convenience.

Laravel-specific product consequence: this package is a non-option, so the decision collapses. It registers via AppKernel::registerBundles() and a YAML config tree; Laravel has no kernel bundles and no bundle config loader. It will not bootstrap, and its 2017-era composer constraints will fight a modern lockfile. The PM-level takeaway is that a search result is not a candidate — the Laravel answer to "dompdf in Laravel" is barryvdh/laravel-dompdf (same engine, same two verbs, maintained) or binding Dompdf\Dompdf in a service provider yourself. Everything below is written so the renderer decision survives regardless of which wrapper you pick.

Platform-roadmap signal worth escalating. Symfony 2 reached end-of-life in November 2018; the last release here is February 2017. Any adoption implicitly pins a slice of the product to a dead framework generation. That is a roadmap fact a PM owns, not an engineering detail to be absorbed silently.

Use cases this pattern fits: text-heavy invoices, receipts, statements, tickets, packing slips, internal reports — server-rendered HTML already exists, fidelity is "good enough," volume is modest, offline/air-gapped operation is a requirement (dompdf needs no browser or binary). Use cases that route elsewhere: pixel-accurate brand templates, flexbox/grid, web fonts at scale, JS-rendered charts, running headers/footers over long paginated reports, PDF/A or accessibility compliance, digital signatures, or high-throughput batch jobs — those are wkhtmltopdf/Snappy, headless Chrome/Browsershot, or Gotenberg decisions, and no wrapper changes that.

Maintenance posture to set explicitly: with 0 stars, 0 dependents, and a single 2017 release, adopt this as source code you own, not a dependency you consume — or don't adopt it. The default should be the latter.

When to Consider This Package

Consider it only when all of these hold:

• You are on Symfony 2.x and need PDF output as a stopgap inside the current release cycle.
• You have deliberately chosen dompdf as the engine (offline, pure-PHP, no system binaries).
• Templates are yours and fidelity requirements are modest.
• Volume is low enough that synchronous, in-request rendering is acceptable (expect hundreds of milliseconds to seconds per document).
• A named owner will vendor or fork it, patch for your PHP version, and track dompdf/dompdf advisories independently.

Look elsewhere when any of these hold:

• You're on Laravel. It cannot register. Use barryvdh/laravel-dompdf, or define Dompdf\Dompdf in a service provider — the latter is genuinely small and keeps you off both wrappers.
• You're on maintained Symfony (5/6/7) or PHP 8.1+. Use dompdf/dompdf directly with a service definition; you get the same two verbs with current PHP support and no EOL transitive drag.
• Visual fidelity is the driver. Browsershot or Gotenberg. Don't fund a fight against a renderer that implements a limited CSS subset.
• Throughput is the driver. Move generation to a queue behind an external renderer; pure-PHP in-request rendering becomes a tail-latency and memory problem.
• You need compliance features. PDF/A, PDF/UA, signing, redaction — engine choice, and dompdf isn't it.
• Security review requires a maintained dependency. No upstream triage, no CVE response, no PHP 8 path; composer audit will flag it and can block CI. That's a policy fail independent of code quality.

Signals to weight honestly: the low score matches the observable record — a README, a release list, and no evidence of tests, CI, or documentation beyond installation. The missing dependents are the loudest signal: nobody has validated this against a real production upgrade path, so you would be the first to discover its problems. Not disqualifying on its own, but it means the risk is realized, not hypothetical.

How to Pitch It (Stakeholders)

For executives (one paragraph): We can add PDF export at near-zero license cost using the MIT-licensed dompdf engine, which is mature and maintained. The package in front of us, es/dompdf-bundle, is a thin convenience wrapper that connects that engine to a Symfony 2 application — it is free, but it is also unmaintained: last released in 2017, zero downstream users, built for a framework generation that hit end-of-life in 2018, and not compatible with our Laravel stack at all. My recommendation is to treat PDF generation as a feature we build against the dompdf engine directly, using a maintained Laravel wrapper or roughly twenty lines of service-provider code. The cost isn't the license; it's the ownership — adopting an abandoned wrapper means quietly maintaining someone else's code on someone else's schedule, with no upstream security response, while HTML→PDF remains an injection surface we'd be responsible for hardening ourselves.

For engineering (the short version): The whole feature set is a dompdf service with streamHtml($html, $filename) and getPdf($html), plus YAML es_dompdf.defaults passed through to dompdf options (dpi, defaultPaperSize, defaultFont). Reproduce that interface, not the package. On Laravel, bind a singleton in a service provider and expose the same two methods behind a thin adapter — that keeps call sites stable if we later swap engines. Use barryvdh/laravel-dompdf if you want it off the shelf, or Browsershot/Gotenberg if fidelity or throughput turns out to be the real requirement; keep the renderer decision separate from the wrapper decision so we aren't locked in. Do not force-install the original bundle — its Symfony 2 constraints will fight the lockfile. If someone insists on evaluating it, isolate it in a throwaway container. Either way, pin and monitor dompdf/dompdf itself, because that is where the rendering and the risk actually live.

The one-line decision: Adopt dompdf as the renderer, skip this wrapper — it buys about twenty minutes of wiring and costs a maintenance obligation on a package nobody else is using.