Pdf Generation Bundle Laravel Package

Technical Evaluation

Architecture fit. The first and most important finding for a TPM: this is a Symfony bundle, not a Laravel package. It is written against Symfony's DI container, service tags, compiler passes, ServiceLocator, and PHP attributes consumed by Symfony's autoconfiguration. It has no service provider, no facade, no Laravel-native config publishing. If the target application is Laravel, the bundle cannot be dropped in as-is; the value you get is the interfaces and reference implementations, not the wiring. Treat it as a well-organized reference architecture rather than an install-and-go dependency. Its conceptual design (context → adapter → generator provider → options processor → storage) is portable, but the plumbing is Symfony-specific.

Integration feasibility. For a Symfony/Sylius shop the fit is strong and idiomatic: YAML config cascades from default into named contexts, built-in adapters (knp_snappy, dompdf, gotenberg) are auto-detected, custom adapters are deferred to a compiler pass, and storage is swappable per context (Flysystem, Symfony Filesystem, Gaufrette). For Laravel, integration requires either (a) manually instantiating the interfaces in a bespoke service provider and hand-wiring generators/processors, or (b) running a second Symfony kernel — neither is attractive. The realistic Laravel path is to reuse the domain contracts (PdfGenerationAdapterInterface, OptionsProcessorInterface, PdfStorageInterface) and back them with Laravel-native equivalents (barryvdh/laravel-dompdf, spatie/laravel-pdf / Browsershot / Gotenberg client, Storage facade).

Technical risk. High, for a handful of reasons:

• Maturity: 3 stars, 0 dependents, and a numeric score of ~9.5 (on what is presumably a 100-point scale) with an opportunity score of ~59.8. This is early-stage, unproven in production, and likely a carve-out of Sylius core functionality rather than a battle-tested standalone package.
• Release date anomaly: "Last release 2026-04-16" is in the future. Verify the actual Packagist metadata before committing — it may reflect a placeholder, a timezone issue in the data feed, or a mis-tagged release.
• Runtime dependencies: wkhtmltopdf (via KnpSnappy) is archived and unmaintained, ships an embedded rendering engine with a long CVE history, and is painful to run in containerized environments. Dompdf is pure PHP (easiest ops) but CPU/memory-heavy and weak on modern CSS. Gotenberg is the technically strongest option (stateless HTTP, isolated Chromium, scales horizontally) but adds a service to your infrastructure.
• Surface area: four extension points (adapter, options processor, generator provider, attribute-based autoconfiguration) plus three storage backends plus compiler passes. Powerful, but it means a lot of framework-specific knowledge in your team to debug.

Key questions to raise before adoption:

1. Is the actual target Laravel or Symfony? The answer changes the recommendation from "viable with caveats" to "do not integrate directly."
2. Who maintains this bundle, and is it a fork/carve-out of sylius/sylius internals? If it's a mirror of upstream Sylius code, the maintenance trajectory follows Sylius; if it's an independent effort at 3 stars, it may be abandoned.
3. Which adapter is mandatory for the business requirement (invoice fidelity, digital signatures, batch rendering)? Gotenberg vs. Dompdf is the deciding architectural fork.
4. What is the PDF volume and latency SLO? That determines whether an HTTP-based adapter (Gotenberg) or an in-process adapter (Dompdf) is acceptable.
5. Where must PDFs be stored and for how long (S3/retention/compliance)? The per-context storage locator makes this elegant but requires upfront policy decisions.

Integration Approach

Stack fit. Strongly positive on Symfony/Sylius; negative on Laravel. If the product is Sylius-based, plan to adopt it directly. If the product is Laravel, do not attempt to load the bundle; instead pull the interfaces as a design template.

Migration path.

• Symfony path: composer require sylius/pdf-generation-bundle, add sylius_pdf_generation config with a default context, install one adapter package (knplabs/knp-snappy-bundle, dompdf/dompdf, or gotenberg/gotenberg-php), choose one storage backend, and define named contexts (invoice, receipt, coupon). This is a low-friction first integration — days, not weeks.
• Laravel path: define your own small contracts mirroring PdfGenerationAdapterInterface and OptionsProcessorInterface, implement a DompdfAdapter and a GotenbergAdapter, and bind a ContextAdapterRegistry in a service provider keyed by context name. This reproduces ~80% of the bundle's value in ~1–2 weeks without dragging in Symfony's container semantics.

Compatibility. Confirm PHP version, Symfony minor version, and the exact adapter package versions against your project matrix. The bundle's LogicException on missing adapter classes is a helpful fail-fast, but it means you must install the adapter's Composer package even if a given context is configured but unused at runtime. Verify Flysystem major version — the ecosystem has moved from v1/v2 to v3 and storage adapter classes change accordingly.

Sequencing. Recommended order for either stack:

1. Storage and retention policy first — decide S3 vs. local vs. Gaufrette, and set the local_cache_directory for remote backends so resolveLocalPath() works (this is the sharpest operational edge: remote storage implementations lazily materialize a local copy).
2. Adapter choice second — start with Dompdf for fastest onboarding (no external binary), then move to Gotenberg once volume or visual fidelity demands it. Do not lead with KnpSnappy/wkhtmltopdf.
3. Context taxonomy third — model contexts after business documents (invoice, credit_note, coupon) not after templates.
4. Options processors last — use them (or their framework-native equivalents in Laravel) for paper size, margins, allowed-files security, and signature settings; keep options out of YAML.

Operational Impact

Maintenance. This is the dominant operational concern. At 3 stars and 0 dependents, you are effectively on the hook to fork or vendor the package if it stops updating. MIT licensing makes that legally trivial, but it converts the bundle from "dependency" to "internal component with an upstream mirror." Budget for a quarterly review of upstream commits and a fallback plan: keep the adapter interfaces thin enough that swapping to a maintained alternative (e.g., direct Gotenberg client, or Laravel-side spatie/laravel-pdf) is a sprint, not a quarter.

Support. No vendor SLA, no commercial backing visible. Support model is community/Sylius channels plus reading the source. The in-repo AGENTS.md is unusually good documentation and materially lowers ramp-up, but it is the team's own words, not external validation.

Scaling.

• Dompdf — scales vertically at best; memory-heavy, single-document throughput low, no concurrency safety. Fine for low-volume invoicing, not for batch generation or per-request on-demand PDFs at scale.
• KnpSnappy/wkhtmltopdf — process-per-document, expensive, and the binary's age makes it a liability; avoid for greenfield.
• Gotenberg — the only genuinely horizontal-scaling option here: stateless HTTP, containerizable, scales with your HTTP tier. Requires that you operate (or buy) the Gotenberg service and treat it as a first-class dependency with health checks and circuit breaking.
• Storage — Flysystem over S3 is the scalable choice; ensure local_cache_directory is on fast local disk and has a bounded TTL/eviction policy, because lazy materialization in resolveLocalPath() can silently fill disks.

Failure modes to instrument from day one.

• Adapter package present but underlying binary (wkhtmltopdf/Chromium) missing or not on PATH → runtime exception on first use; surface via health check.
• Generator provider returning a shared (not fresh) instance → cross-context state bleed; the bundle's RegisterKnpSnappyPrototypePass exists precisely to avoid this, but custom adapters can reintroduce it.
• Options processors mis-ordered by priority → silent rendering regressions (wrong paper size, missing headers). Pin priorities explicitly.
• Storage failures on resolveLocalPath() for remote backends → cache directory unreadable/unwritable; alert on disk utilization.
• Template rendering errors surfacing as PDF generation errors → separate Twig-render failures from adapter failures in logging so troubleshooting leads somewhere.
• Adapter type mismatch across contexts (e.g., context configured with an unknown adapter name) → deferred to compiler pass and resolved at boot; fail fast in CI, not in production.

Ramp-up. For a Symfony team, one engineer can go from reading AGENTS.md to a working invoice context in 1–2 days. For a Laravel team, expect 1–2 weeks to re-implement the pattern and to unlearn Symfony's container idioms; the bundle's concepts (context routing, swappable adapters, option-processing chain) transfer cleanly, but none of the DI wiring does. Across the organization, the main skill investment is ops for whichever adapter you pick — running Chromium/Gotenberg in containers is the real learning curve, not the PHP.

TPM recommendation. Do not adopt as a direct dependency for a Laravel application — architecturally incompatible at the framework layer. For a Symfony/Sylius application, it is a clean, well-factored option provided you (a) verify the release-date anomaly on Packagist, (b) commit to Gotenberg or Dompdf rather than wkhtmltopdf, and (c) accept custodial risk given the 3-star/0-dependent footprint with a documented exit path. In either case, the highest-value artifact to borrow is the interface design and context-routing model, which is sound and portable.