Dompdf Bundle Laravel Package

Product Decisions This Supports

Scope correction first, because it changes the decision: this is a Symfony 2 bundle, not a Laravel/PHP package in the general sense. Its entire deliverable is Symfony kernel glue — a Bundle subclass, a DI extension, and a config tree that exposes DOMPDF as $this->get('slik_dompdf'). In a Laravel codebase, none of that is loadable. Resolve this before anything else; if the estate is Laravel, the functional equivalents are barryvdh/laravel-dompdf or dompdf/dompdf bound directly in a service provider.

With that caveat, the decisions this artifact genuinely informs:

• Feature scoping — server-side document generation. Invoices, receipts, statements, packing slips, tickets, compliance reports, and "export to PDF" buttons. That is the whole capability under discussion; everything else is packaging.
• Build vs. buy at the renderer layer. The real decision is DOMPDF vs. alternatives, not this bundle vs. that bundle. DOMPDF is pure PHP — no headless browser, no binaries, no external service — which suits low-volume, template-driven documents on constrained hosting. It is a poor fit for pixel-perfect design, flexbox/grid, web fonts, or anything needing JavaScript execution.
• Build vs. buy at the wrapper layer. This bundle is worth roughly a dozen lines of service-definition config. It is not an architectural component and should not be evaluated as one. The question is "take a dependency to save an afternoon, or own a 30-line adapter?"
• Roadmap placement. PDF export is a commodity checkbox, not a differentiator. Scope it as a thin, swappable adapter behind an internal PdfRenderer interface so the engine can change (DOMPDF → headless Chrome/Browsershot → hosted API) without touching feature code.
• Vendor-risk and stack-lifecycle policy. 9 stars, 0 dependents, no meaningful release cadence, and a target framework that reached end of maintenance in November 2018. That is a "do not standardize on" signal feeding directly into tech-stack and patching policy.
• Prioritization against alternatives. If requirements include async generation, high volume, or complex layouts, the decision shifts to queued workers plus a headless-Chrome renderer and this package drops out entirely.

When to Consider This Package

Consider it only when all of the following hold:

• You maintain an existing Symfony 2.x app that already has this bundle in composer.json and is not being modernized.
• You want DOMPDF configuration (font paths, temp dir, default paper size, chroot) managed via DI rather than instantiated by hand.
• Documents are simple, low-volume, and template-driven (Twig-rendered HTML with basic CSS).
• You accept pinning an old PHP constraint and are prepared to fork or vendor the code if it breaks.

Look elsewhere when any of these is true:

• New build, Symfony 3.4+/5/6/7, or Laravel. Use dompdf/dompdf directly behind your own interface; for Laravel, barryvdh/laravel-dompdf. For higher fidelity, spatie/browsershot, knplabs/knp-snappy, or mpdf/mpdf (stronger CJK and page control).
• Layout fidelity matters. Design expects flexbox, grid, web fonts, or JS-driven charts. No wrapper fixes that.
• Volume or latency matters. PDF generation should be queued; a DI wrapper adds nothing to throughput and can mask blocking calls in the request cycle.
• Security posture matters. DOMPDF has a history of advisories around remote resource loading, chroot escapes, and SSRF via external stylesheets/images. An unmaintained wrapper makes it easy to sit on a stale, unpatched core. Any adoption needs explicit chroot pinning, remote-asset disabling, and a documented upgrade path for the core library.
• You need vendor support or an SLA. Nine stars and zero dependents means no community safety net; a hosted rendering API is the honest buy option.

How to Pitch It (Stakeholders)

To executives — one paragraph: We evaluated slik/dompdf-bundle for PDF generation and do not recommend adopting it. It is a very thin, essentially unmaintained wrapper around the open-source DOMPDF library, built for Symfony 2.x — a framework generation that has been end-of-life since 2018 — with negligible adoption. It offers no capability we cannot get by depending on DOMPDF directly in roughly thirty lines of our own code. The customer-facing capability (invoices, statements, export-to-PDF) is unaffected; only the packaging choice changes. Recommended path: adopt DOMPDF upstream, or a headless-Chrome renderer if design fidelity is a requirement, behind a thin internal abstraction so we can swap engines later.

To engineering — the substance:

• The value lives in dompdf/dompdf, which is actively maintained. The bundle's contribution is container wiring and a config tree — reproducible in an afternoon with one service provider, with full control of versions.
• Put it behind an interface (PdfRenderer::render(string $html, array $options): string). This is the only durable design decision: it lets us migrate from DOMPDF to Browsershot when a design requirement forces the issue, without rewriting call sites.
• Treat PDF generation as a job, not a request-cycle call. Queue it, store the artifact, serve a signed URL — true regardless of renderer.
• If DOMPDF specifically is required: pin a current dompdf/dompdf release, set chroot to a dedicated asset directory, disable remote image/style loading, and cap input size and page count. Those controls are ours to own; the wrapper will not provide them.
• Spike cost is about half a day to validate layout fidelity against a representative real template (an actual invoice, not a hello-world). Do this before committing, because DOMPDF's CSS limitations are the most likely source of rework.

Bottom line: the underlying capability is worth building; this package is not worth depending on. Score it as a reference implementation to skim, not a dependency to adopt.