- Is nmalo/dompdf-bundle a Laravel package?
- No. It is a Symfony 2 bundle, a fork of the long-abandoned SlikNL/DompdfBundle, and it ships a Symfony Bundle class, a DI extension, and a service definition wired through Symfony's container and config tree. There is no service provider, no facade, and no Laravel version constraint anywhere in the codebase. If you are evaluating it for a Laravel application, the package is the wrong framework entirely.
- Can I install nmalo/dompdf-bundle in a Laravel application?
- Not in any meaningful way. None of its Symfony container wiring maps onto Laravel's service-provider model, so you would have to copy the source into your app and hand-wire the Dompdf client yourself, which defeats the purpose of using a package. The better path is to depend on dompdf/dompdf directly behind a thin wrapper service, or use barryvdh/laravel-dompdf, which is the established Laravel equivalent and is actively maintained.
- What is the best Laravel alternative for generating PDFs from Blade views?
- barryvdh/laravel-dompdf is the de facto standard: it provides a service provider, a facade, and publishable configuration, and you can pass Blade-rendered HTML straight into it. Bind your own PdfRenderer interface in the container and call the package behind that seam so you can swap the engine later. That change is typically a same-day migration and removes the entire abandonment and compatibility risk profile of this bundle.
- Which Symfony version does nmalo/dompdf-bundle support?
- It targets Symfony 2.x, which reached end-of-life in November 2018 and receives no security fixes. The bundle structure, DI extension, and config tree are all Symfony 2 era, so it will not work on Symfony 5, 6, or 7 without a rewrite. The only realistic fit is a legacy Symfony 2 application that already depends on Dompdf and cannot move off it.
- Is nmalo/dompdf-bundle still maintained?
- There is no evidence of active maintenance. It has zero stars and zero dependents, comes from a fork-of-a-fork provenance chain, and its upstream parent SlikNL/DompdfBundle is archived. There is no CI, no release cadence, and no documented security response process, and the single maintainer means there is no community to lean on if it breaks. Adopting it means committing to fork and maintain it yourself.
- What PHP and Dompdf versions does nmalo/dompdf-bundle require?
- Legacy Symfony 2 bundles of this vintage typically constrain PHP to the 5.x through 7.1 era and pin dompdf/dompdf to an old major release. That combination blocks PHP 8.x upgrades and prevents you from picking up modern Dompdf security fixes. It also creates dependency-resolution conflicts as soon as anything else in your Composer tree moves forward.
- Is it safe to use an unmaintained PDF bundle in production?
- The risk is high and concentrated in supply chain and staleness. A zero-star, zero-dependent, single-maintainer abandonware fork is exactly the profile of a package that quietly accumulates unpatched CVEs with nobody reviewing changes. If your organization has a compliance or third-party dependency review gate, this package will almost certainly fail it. Pair that with the fact that running Symfony 2 at all is a separate and larger compliance finding.
- Can I use dompdf/dompdf directly in Laravel instead of a bundle?
- Yes, and for many teams that is the strictly better option. Require dompdf/dompdf with Composer, write a small service that takes HTML and returns a PDF response, and bind it to an interface in the container. Dompdf itself is maintained and fits any PHP stack; it is only the bundle wrapper that does not travel. Keeping it behind an interface also lets you replace the engine later without touching call sites.
- How do I migrate off nmalo/dompdf-bundle?
- On Laravel, install barryvdh/laravel-dompdf or dompdf/dompdf directly and bind a PdfRenderer interface in the container. For a Symfony application, move to a maintained Symfony bundle or wire the library manually through your own service definition. In both cases keep the renderer behind an interface and migrate call sites incrementally so download and stream endpoints keep working throughout. Once the seam is in place, swapping to headless Chrome later is a contained change.
- Does Dompdf render modern CSS like flexbox and grid correctly?
- No. Dompdf is a pure-PHP renderer with known CSS limitations: flexbox and grid support is minimal, web-font handling is partial, and JavaScript is not executed at all. If HTML/CSS fidelity matters for invoices, statements, or branded reports, a headless Chrome renderer such as Browsershot, Puppeteer, or a managed PDF API will produce far more accurate output. Note that these fidelity bugs come from Dompdf itself, so switching wrappers alone will not fix them.