Pdf Bundle Laravel Package

Product Decisions This Supports

• Feature scoping for document output. Any roadmap item that produces a downloadable or emailable PDF — invoices, receipts, statements, certificates, branded reports, batch exports — needs a rendering layer. This package is one candidate for that slot, and the assessment forces the team to name the rendering requirement (HTML fidelity, templating, drivers) before committing.
• Build vs. buy vs. fork. The package is itself a fork of psliwa/pdf-bundle with a Symfony 3.3 compatibility shim. That reframes the decision: you are not evaluating a product, you are deciding whether to own a thin, unmaintained wrapper or adopt a maintained upstream. The PM decision is "adopt a dependency we can outlive," not "build a PDF engine."
• Dependency risk policy. 0 stars, 0 dependents, and a single-purpose fork are hard signals. The most valuable output of this evaluation is a repeatable rule for the dependency register: no adoption without adoption signals (stars, dependents, release cadence, CVE history) unless the code is small enough to vendor and own.
• Framework fit as a gating criterion. This is a Symfony bundle, not a Laravel package — no service provider, no publishable config, no facade. If the question was "what do we use in Laravel," this package answers it in the negative and saves an evaluation cycle.
• Upgrade-path planning. A Symfony 3.3-targeted bundle implies a legacy application. Adopting it is a decision about which legacy surface you accept as frozen, and it should be logged as technical debt with an owner and a removal trigger.

When to Consider This Package

Consider it only under narrow conditions:

• You are on a Symfony 3.3 application that cannot be upgraded in this cycle, and your existing psliwa/pdf-bundle pin is blocked by a compatibility break.
• You need a small, MIT-licensed, self-contained rendering wrapper and are prepared to vendor and own the code — reading it, patching it, and accepting that no upstream fixes will arrive.
• The PDF output is internal or low-stakes (admin exports, back-office reports) where visual fidelity and long-term support are not contractual.

Look elsewhere when any of the following is true:

• You are on Laravel. Use barryvdh/laravel-dompdf, spatie/laravel-pdf, or a Gotenberg-based service — packages with real integration, config publishing, and active maintenance.
• You are on Symfony 4+ / 5+ / 6+ / 7. Use a maintained bundle (KnpSnappyBundle with knplabs/knp-snappy, or a direct dompdf/mpdf integration). The 3.3 shim is dead weight at best, a conflict at worst.
• PHP 8+ is required. A Symfony 3.3-era fork is not a safe assumption for modern runtime support; verify before promising anything.
• Output is customer-facing or regulated. Invoices, tax documents, and contracts need predictable rendering, a maintenance commitment, and a security review path. Zero dependents means zero downstream scrutiny of this code.
• You need modern CSS fidelity. Flexbox, grid, and web fonts generally require a headless-Chrome approach (Gotenberg, Browsershot) rather than traditional PHP PDF libraries.
• You have a dependency policy with minimum adoption thresholds. This package fails on every axis: stars, dependents, release history, and ecosystem review.

How to Pitch It (Stakeholders)

To executives: There is a cheap, MIT-licensed option for generating PDFs from a legacy Symfony 3.3 application. It is a fork of an existing bundle, has no measurable adoption, and no active maintainer. Recommendation: treat it as a time-boxed stopgap, not a platform commitment. If PDF output is on the roadmap, fund a short spike against a maintained alternative first — the licensing cost is identical (free), so the only variable is long-term ownership risk. We should not put a customer-facing document pipeline on a package with zero dependents.

To engineering: This is psliwa/pdf-bundle plus a Symfony 3.3 compatibility shim. Expect to own it outright: no upstream patches, no CVE feed, no issue tracker. Mitigations if we proceed — vendor the code into the repo, wrap it behind an internal PdfRenderer interface so the underlying driver can be swapped, pin the version explicitly, and add it to the dependency register with a named owner and a removal trigger tied to the framework upgrade. Default position is to select a maintained alternative unless the Symfony 3.3 constraint is genuinely immovable.