- Is littlerocket/pdf-bundle compatible with Laravel?
- No. It is a Symfony bundle: it ships a Bundle subclass, a DI Extension, and a config tree that Laravel does not register. In a Laravel application the autoconfiguration, service wiring, and config schema are unusable, so only the underlying rendering library could be reused directly. Treat it as a library you might vendor, not a package you install.
- How do I install littlerocket/pdf-bundle?
- For a Symfony app you would require littlerocket/pdf-bundle with Composer and register the bundle, but for Laravel do not install it. Composer is likely to fail on PHP 7.x platform constraints or symfony/* pins that conflict with Laravel 10 or 11. Using --ignore-platform-reqs is not an acceptable production workaround. If you must use the code, fork it under your own namespace and wrap it behind a narrow interface.
- What PHP versions does littlerocket/pdf-bundle support?
- The package is a PHP 7-era fork marked 'Fixed for PHP7' and released in 2023, so assume a PHP 7.x floor. Its symfony/* constraints are likely to conflict with modern Laravel runtimes on PHP 8.1 or 8.2. That caps your host application's runtime and blocks adoption of PHP 8.x language features. Confirm the actual constraint set in its composer.json before planning anything.
- How do I configure page size, orientation, and margins?
- In Symfony, configuration lives in the bundle's config tree and DI extension, where you can adjust page size, orientation, margins, and output options in one place. In Laravel that mechanism does not exist because bundles are not registered. You would have to construct and configure the renderer manually or build your own config layer. This is one reason the bundle's value is largely dead weight outside Symfony.
- Can littlerocket/pdf-bundle render HTML to PDF?
- The description advertises HTML-to-PDF, but the underlying PHPPdf engine is an XML-markup DSL with stylesheets and node templates, not a modern HTML/CSS renderer. Expect to write PHPPdf templates rather than reuse complex web HTML. If your requirement is HTML/CSS fidelity, choose a maintained engine instead.
- Is littlerocket/pdf-bundle maintained and safe for production?
- No, treat it as high risk. The fork has zero stars, zero dependents, a single maintainer, and no community or CVE triage, which means no advisory feed and no downstream production signal. PHPPdf is effectively abandoned and XML template parsing is a classic XXE and entity-expansion surface if any fragment is user-influenced. Do not adopt it for production unless you own the fork and the patching.
- What are the alternatives to littlerocket/pdf-bundle for Laravel PDF generation?
- For Laravel, use a maintained engine such as dompdf, mPDF, Browsershot/Puppeteer, or a Gotenberg sidecar behind your own PdfRenderer interface. The interface matters more than the engine because it makes the renderer swappable. Port two or three representative templates, including your worst one, and measure layout fidelity before committing.
- Can I use littlerocket/pdf-bundle for invoices and reports?
- Only if you have legacy PHPPdf XML templates you must preserve. For greenfield invoices or reports the package is disqualified because of the framework mismatch, PHP 7-era codebase, and abandonment risk. Most document sets are mostly simple letterheads with a few pathological table or pagination cases, so test the hard ones. A maintained alternative will be cheaper than dragging this fork forward.
- How do I test PDF output from littlerocket/pdf-bundle?
- Build a golden-file harness before changing anything: capture byte-level or image-diff baselines for every document you produce. Then port two or three templates, including the worst one, and compare layout fidelity rather than just checking that a file is generated. This harness also lets you evaluate replacement engines objectively. Without baselines you cannot prove a migration is safe.
- Can I migrate existing PHPPdf XML templates to Laravel?
- Maybe, but not by installing this bundle. Inventory every PDF, classify complexity, and decide whether exact reproduction is truly required; if not, rewrite on a maintained engine. If legacy templates must be preserved, vendor a fork you control under your own namespace and bind it behind a PdfRenderer interface with render(TemplateRef, Data): PdfDocument. That converts abandonment risk into a routine refactor.