Dompdf Bundle Laravel Package

Product Decisions This Supports

• PDF generation capability — invoices, receipts, statements, reports, tickets, and downloadable exports. This bundle is a thin Symfony 2 DI wrapper around dompdf/dompdf; it nominally supports shipping a "download as PDF" feature, not a strategic decision.
• Build vs. buy (engine selection) — the real comparison is dompdf/dompdf vs. headless-Chrome/wkhtmltopdf renderers vs. hosted APIs (DocRaptor, PDFShift, etc.). This wrapper is too small to move that decision either way.
• Roadmap framing — PDF export is a recurring roadmap item, but this fork is not a roadmap enabler: it targets Symfony 2, which reached end-of-life in November 2019.
• Use cases it could serve — only legacy Symfony 2 applications already depending on SlikNL/DompdfBundle that need a same-namespace fork. Nothing else.
• Framing correction — this is a Symfony 2 bundle, not a Laravel package. The "Laravel" framing in the ticket doesn't apply; for Laravel the relevant options are barryvdh/laravel-dompdf or dompdf/dompdf directly.

When to Consider This Package

• Consider only if: you are maintaining an existing Symfony 2 app that already uses SlikNL/DompdfBundle and need a drop-in fork (e.g., the original is abandoned or pinned to an old PHP version).
• Avoid for new builds — Symfony 2 is EOL, receives no security patches, and its PHP constraints conflict with all modern frameworks.
• Social proof is zero — 0 stars, 0 dependents, single maintainer. No ecosystem validation, no community support, no issue-triage signal.
• Look elsewhere if: you need Laravel (use barryvdh/laravel-dompdf or dompdf/dompdf), need modern Symfony (use a maintained alternative), need stronger CSS/JS fidelity (headless Chrome/Puppeteer), or need an SLA/vendor support (commercial PDF APIs).
• MIT license is permissive — but licensing is not the blocker; abandonment and platform age are.

How to Pitch It (Stakeholders)

To executives: This is a 0-star, 0-dependent, single-maintainer fork of a Symfony 2 bundle. Symfony 2 has been end-of-life since 2019, so adopting it creates security and maintenance exposure with no offsetting benefit. The underlying rendering engine (DomPDF) is reasonable for simple HTML→PDF, but we should consume it directly or through a maintained adapter. Recommendation: do not adopt. If PDF generation is on the roadmap, budget a one-week spike comparing dompdf/dompdf, a headless-Chrome renderer, and a hosted API on fidelity, throughput, and total cost of ownership.

To engineering: It's a small dependency-injection wrapper, not a meaningful contribution — the equivalent service definition can be vendored in an afternoon. The MIT license is fine, but the fork adds nothing over upstream and brings baggage: Symfony 2 PHP constraints, no CI/test signal, and no active maintainer. Decision: no-go as a dependency. If we need DomPDF behavior, depend on dompdf/dompdf directly behind our own thin adapter so the rendering engine remains swappable when fidelity or performance requirements grow.