Pdf Merger Bundle Laravel Package

Product Decisions This Supports

• Document assembly features: Merging server-generated PDFs (invoices, statements, payslips, contracts, onboarding packs) into a single deliverable before email, download, or archival. This is the primary product use case the bundle exists to unblock.
• Build vs. buy: A thin Symfony service wrapper over the tomsgu/pdf-merge library means the decision is really "integrate a library" versus "write a merger in-house." Buying is roughly a one-to-two-day integration; building means owning low-level PDF object handling, which is rarely where product differentiation lives.
• Roadmap sequencing: Useful as an enabler for features like consolidated monthly statements, "download all attachments" flows, compliance/audit packet exports, or multi-document e-signature envelopes. It does not itself provide generation, templating, signing, or delivery.
• Scope boundary: It merges PDFs. If the roadmap needs HTML-to-PDF rendering, form filling, redaction, password protection, or digital signatures, those remain separate build/buy decisions and should not be conflated with this adoption.
• Stack caveat for the build decision: Despite being a PHP package, this is a Symfony bundle with framework-specific service wiring. For a Laravel codebase, adoption cost is higher than it appears and the decision should default to using the underlying tomsgu/pdf-merge library directly, or a Laravel-native PDF toolkit already in the stack.

When to Consider This Package

Consider it when all of the following hold:

• The application is Symfony, on a version the bundle supports, with autoconfiguration enabled — the bundle's only real value over the underlying library is DI wiring and configuration.
• Inputs are PDFs you generate or control, and are compatible with the underlying FPDI-style parsing constraints (not encrypted, no unsupported compression or object streams).
• The need is genuinely merge/concatenate — not generate, edit, annotate, sign, or convert.
• You are comfortable pinning a dependency with 8 stars, 0 dependents, and effectively a single maintainer; the license (MIT) at least means you can fork if it stalls.
• The last release date (2026-01-14) is verified against the actual Symfony/PHP version support matrix rather than assumed from a version string.

Look elsewhere when:

• The stack is Laravel or framework-agnostic. Use tomsgu/pdf-merge directly, or evaluate a more actively maintained toolkit (e.g., a FPDI/TCPDF-based wrapper, mPDF, or a commercial SDK) that also covers generation.
• You need more than merging. Bundling generation, templating, signing, or OCR into one vendor choice usually beats stitching three low-adoption packages together.
• Scalability or reliability is load-bearing. Merging large or numerous PDFs is memory-bound; validate limits before committing a customer-facing flow to it.
• You require vendor support, SLAs, or a security-response process. A single-maintainer package with near-zero adoption does not provide these.
• You already ship a PDF stack. Adding a second PDF engine for merging is usually a worse outcome than using the merger capability already present.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed PHP component that lets us combine multiple PDFs into one file — the plumbing behind features like consolidated statements or "download everything as a single packet." Cost is near zero and integration is measured in days, not sprints. The risk is not technical, it is supplier risk: the project has minimal adoption, a single maintainer, and no commercial support. Recommendation is to treat it as an internal, forkable utility rather than a strategic dependency, and to timebox a short spike before any customer-facing commitment.

To engineering: It is a Symfony bundle wrapping the tomsgu/pdf-merge library — the bundle adds DI configuration, not capability. Do not pull the bundle into a Laravel service; depend on the library directly and wrap it behind our own PdfMerger interface so the vendor is swappable in one place. Validate three things in the spike: (1) our generated PDFs parse cleanly under the underlying FPDI constraints; (2) peak memory on our largest realistic merge set; (3) Symfony and PHP version compatibility against the actual composer constraints, not the release date. Pin the version, commit a lockfile, and keep a fork path open.

Recommendation: Conditional go — approve as an internal utility behind an abstraction, gated on the spike; do not standardize on it as the company's PDF strategy.