- Is kitpages/pdf-bundle compatible with Laravel?
- No. kitpages/pdf-bundle is a Symfony bundle, not a Laravel package. It ships a Symfony Bundle class, DI extension, and service definitions that depend on Symfony's container, event dispatcher, and configuration tree, none of which exist in Laravel. There is no service provider, facade, or config publishing, so using it in Laravel would mean porting it rather than installing it.
- Can I install kitpages/pdf-bundle in a Laravel 10 or 11 app?
- Not realistically. The package is a dormant Symfony 2-era project with PHP 5.3/5.4 idioms and old Symfony constraints that conflict with the Symfony 6/7 components Laravel 10/11/12 require. Forcing an install with ignore-platform-reqs typically leads to Composer resolution failures or, worse, silent downgrades of shared Symfony components. Treat Composer conflicts here as a hard stop.
- What does kitpages/pdf-bundle actually do?
- It is a thin Symfony orchestration layer over a PDF renderer, historically TCPDF and/or wkhtmltopdf with FPDF/FPDI in the overview. It exposes a PdfManager-style service plus Symfony configuration for page size, orientation, and output mode. The value is the pattern, not the code: a small service wrapper around a renderer.
- What are the best Laravel alternatives for generating PDFs?
- The idiomatic Laravel options are barryvdh/laravel-dompdf for pure PHP DomPDF rendering, barryvdh/laravel-snappy for a wkhtmltopdf wrapper, and spatie/browsershot for headless Chromium with the best CSS fidelity. Each ships a Laravel service provider, config file, and facade, which are exactly the affordances kitpages/pdf-bundle lacks. Choose based on your HTML/CSS fidelity requirements and whether your environment permits system binaries.
- How do I migrate from kitpages/pdf-bundle to a Laravel-native PDF package?
- Treat the bundle as a reference implementation, not a dependency. Define an application-owned contract such as App\Contracts\PdfRenderer with a render method returning a StreamedResponse, implement it once against your chosen Laravel package, and bind it in a service provider. Keeping call sites behind that contract gives you a one-file swap if the renderer changes later.
- Does kitpages/pdf-bundle support PHP 8 or Laravel 12?
- There is no evidence of PHP 8 or Laravel 12 support. The repository shows 2 stars, 0 dependents, a score of 0.14, no modern type declarations, no PHP 8 support, and no maintainer activity. It should be treated as unsupported for modern Laravel applications.
- Which rendering backend does kitpages/pdf-bundle use, and does it need wkhtmltopdf?
- The bundle historically wrapped TCPDF and/or wkhtmltopdf, with FPDF/FPDI named in the overview, so the rendering backend depends on the version and configuration. If your target setup uses wkhtmltopdf, the environment must permit that binary, which is often a deployment constraint. Many Laravel teams avoid system binaries by using pure PHP DomPDF or headless Chromium via Browsershot.
- Is kitpages/pdf-bundle safe to use in production?
- No, the technical risk is high. The project is unmaintained, has no security response process, and importing it would pull an old Symfony transitive surface into a modern Laravel app. Production applications should use a maintained Laravel-native PDF package with an active release history instead.
- What licensing applies to kitpages/pdf-bundle and its PDF renderers?
- You need to verify the bundle's own license in the repository, but the underlying renderers carry their own terms: TCPDF is LGPL and wkhtmltopdf is LGPLv3. Those licenses can impose redistribution obligations depending on how you deploy or redistribute the software. Licensing is another reason to prefer a Laravel package with clear, current terms.
- How should I test PDF generation after replacing kitpages/pdf-bundle in Laravel?
- Write feature tests against your PdfRenderer contract using a fake driver, asserting the response is a streamed download with the expected content type and filename. For real-render smoke tests, generate a known fixture and assert page count or extracted text rather than comparing PDF bytes exactly. Keep render-time assertions loose and move slow PDF tests into a separate suite.