Pdf Generation Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for document generation: This bundle is a concrete "buy" option that wraps existing PDF engines (wkhtmltopdf via KnpSnappy, Dompdf, Gotenberg/Chromium) behind a stable interface. A PM can defer the "which PDF engine?" decision entirely—adapter swapping is a config change, not a rewrite. This preserves roadmap flexibility for invoice, receipt, coupon, and statement generation features.

• Multi-tenant / multi-brand document strategy: Context routing (invoice, receipt, coupon, default) lets one codebase serve different document types with different engines, storage backends (Flysystem/S3, Symfony filesystem, Gaufrette), and options. This directly supports go-to-market in regulated vs. non-regulated segments without forking the codebase.

• Feature scope for document pipelines: Because storage, rendering, and file persistence are separate contracts (PdfFileManagerInterface, PdfStorageInterface, PdfFileGeneratorInterface), a PM can stage delivery—ship rendering first, add S3 archival, retention policies, and download endpoints later—without resequencing the roadmap.

• Infrastructure migration decisions: Swapping from wkhtmltopdf (aging, security-sensitive) to Gotenberg/headless Chromium is a per-context config change. This de-risks the "modernize PDF rendering" roadmap item into an incremental, reversible rollout rather than a flag-day migration.

• Customization without engineering escalation: Options processors and custom adapters/extensions mean customer-specific PDF tweaks (paper size, headers, allowed files, security flags) become configuration tasks rather than core-product roadmap items—useful for enterprise deals.

• Use cases supported: invoicing (Sylius-native context), receipts, coupons/vouchers, statements, contracts, shipping labels—anywhere HTML/Twig → PDF is needed with per-type output requirements.

When to Consider This Package

Adopt when:

• The product is on (or moving to) Symfony/Sylius and needs server-side PDF generation from HTML/Twig.
• Multiple document types with divergent formatting, engine, or storage requirements are on the roadmap—this bundle's context abstraction is its differentiator.
• There is a realistic need to switch PDF engines over time (licensing, security, quality of rendering—especially CJK/Unicode or CSS paged media).
• Documents need to be persisted to pluggable storage (S3, local filesystem) with a local-path materialization for email/preview flows.

Look elsewhere or pause when:

• The stack is not Symfony (the value is almost entirely DI wiring and Symfony config; porting costs erase the benefit).
• A single PDF template with one engine is all that is ever needed—a thin wrapper around Dompdf/Snappy is simpler and removes a dependency.
• The team cannot own the operational side of wkhtmltopdf/Gotenberg (a service to run, binaries to update, container images to ship).
• Maturity risk (critical for a PM): 3 stars, 0 dependents, no downstream usage evidence. Treat this as early-stage. Budget for reading source, pinning versions, and accepting potential breaking changes. Require a proof-of-concept and a written fallback plan (direct Dompdf/Snappy usage) before committing it to a customer-facing invoicing path.
• Bundle-specific concerns: adapter-agnostic config means the adapter packages themselves must be installed and compatible; the "deferred adapter" mechanism helps custom adapters but adds a learning curve.

How to Pitch It (Stakeholders)

For executives (30 seconds): "This bundle lets us generate invoices, receipts, and statements from the same HTML templates we already have, but lets each document type use a different PDF engine and storage destination—all configuration, not new code. It means we can change PDF providers (for cost, security, or quality) without rewriting our document features, and it isolates us from vendor lock-in. The main caveat: it's an early-stage package (tiny community, no known production users), so we'd pilot it behind our invoicing feature rather than betting the platform on it—and keep a one-afternoon fallback to a direct library integration."

For engineering leads: "MIT-licensed Symfony bundle with clean interfaces—TwigToPdfRenderer, HtmlToPdfRenderer, PdfGenerationAdapterInterface, and per-context PdfStorageInterface—plus attribute-based extension points (AsPdfGenerationAdapter, AsPdfOptionsProcessor, AsPdfGeneratorProvider). Compiler passes wire contexts into service locators, so adapter and storage strategy is per-context config. It removes the need for us to build and maintain adapter routing and storage abstraction ourselves. Trade-offs: small maintainer base, no dependents to benchmark against, so we should vendor-pin it, run a spike, and validate the Gotenberg and Flysystem paths before committing."

For product/roadmap (decision frame):

• Decision enabled: choose "build once, swap engines later" for document generation instead of committing to a single engine.
• Cost of adoption: low integration cost (bundle config), moderate operational cost (PDF service/binaries), moderate risk (immaturity).
• Recommendation: pilot on one non-critical context (e.g., coupons or receipts) with a fallback plan, and revisit for invoicing once the package shows signs of adoption (stars, dependents, release cadence) or after our own successful pilot.