Twig Spreadsheet Bundle Laravel Package

Product Decisions This Supports

• Export/reporting capabilities on the roadmap. This bundle is the "generate a spreadsheet from data" primitive. It supports decisions like "do we ship a one-click Excel export of the customer list / invoice ledger / compliance report in Q3?" without building a spreadsheet engine.
• Template-driven document generation as a product pattern. The distinguishing feature is rendering PhpSpreadsheet templates with Twig. That unlocks a decision a non-engineer cares about: who owns the layout. Instead of engineers hand-coding cell coordinates and styles in PHP, finance/ops can own an .xlsx template (fonts, colors, merged cells, logos) and engineering only fills in the data. This is the difference between "every report change is a sprint ticket" and "every report change is a content edit."
• Build vs. buy vs. wrap. The decision this informs is not "buy this package" but "wrap PhpSpreadsheet rather than build a writer." PhpSpreadsheet itself is the substantial dependency; this bundle is a thin adapter. The PM decision is whether a thin adapter is worth a dependency versus ~1–2 days of glue code inside the app.
• Format coverage as a product requirement. ODS / XLSX / XLS / CSV / PDF (mPDF) are all available "for free" from the underlying library. That lets you decide to ship CSV first and defer PDF, without re-architecting.
• Use cases this maps to: bulk data exports for enterprise customers, financial statements and invoices, scheduled/emailed reports, regulator-ready spreadsheet deliverables, and "download my data" self-service features (GDPR/portability requests).
• Explicitly not a fit for: customer-facing, high-volume, low-latency rendering. Twig-rendered spreadsheets are a batch/job-shaped workload — a queue decision, not a request-path decision.

When to Consider This Package

Consider it only when most of these are true:

• You are on Symfony 3.4–4.x with PHP 7.1–7.4. The stated requirements top out there; this will not install cleanly on Symfony 5.4/6+/7 or PHP 8+ without work.
• Twig is already your templating engine and the team is fluent in it — the value proposition is reusing that mental model, not learning a new DSL.
• Non-developers genuinely own the report layouts, so template files being editable in Excel/LibreOffice is a real workflow win rather than a nice-to-have.
• You need several output formats from one template and don't want to maintain separate CSV and PDF code paths.
• You accept it as a small, pinned, possibly vendored dependency you can maintain yourself.

Look elsewhere if any of these are true — and in 2025 most of them are:

• You are on Laravel. This is a Symfony bundle; there is no Laravel service provider, no config integration, no reason to fight the framework boundary. Use PhpSpreadsheet directly, or a Laravel-native wrapper.
• You need a maintained dependency. Last release was April 2021, roughly four years stale. 2 stars and 0 dependents means effectively no community to catch regressions, no security triage, no Symfony deprecation fixes. That is a supply-chain line item, not a rounding error.
• Modern PHP/Symfony hygiene is required (PHP 8.2+, Symfony 6/7, static analysis, PHPUnit 10+). You will be doing the upgrade work yourself.
• Performance or scale matters. Twig-rendered spreadsheets are memory-hungry; for large exports prefer a streaming writer (openspout/box/spout) over in-memory PhpSpreadsheet.
• You need charts, pivot tables, or rich formatting fidelity beyond what the template already contains — verify against your actual templates before committing.

Net: this is best treated as a pattern to copy, not a library to install. Reading its Twig-macro-over-template approach and reimplementing it on your own stack is likely cheaper than adopting it — and the score profile (opportunity 26, near-zero adoption, stale) says the ecosystem agrees.

How to Pitch It (Stakeholders)

To executives — one paragraph: Spreadsheet exports are a common, high-visibility ask from enterprise customers, and doing them badly costs real engineering time every time a layout changes. This package demonstrates a cheap, proven pattern: business teams own the spreadsheet template in Excel, engineering just fills in the data. It gets us XLSX, CSV, ODS and PDF from a single template, so we can ship CSV first and add PDF later without rework. However, the package itself is a four-year-old, essentially unused Symfony-only adapter — so my recommendation is to adopt the pattern, not the dependency, and budget roughly one to two engineering days to build the equivalent glue in-house.

To engineering — the substance:

• It is a thin Symfony bundle around PhpSpreadsheet that lets you render .xlsx/.ods template files through Twig, including macro and include. The template holds formatting; Twig holds data. That separation is the whole idea and it is a good one.
• Costs are low: MIT licensed, small surface area, no exotic dependencies. The only real runtime dependency is PhpSpreadsheet plus mPDF if you want PDF.
• Risks are concrete: last release 2021, requires PHP 7.1+ / Symfony 3.4+, 2 GitHub stars, 0 dependents, and CI badges pointing at Travis and SensioLabsInsight — both long dead. That combination means no upstream maintenance and no community safety net.
• Recommended path: spend half a day reading the source for the Twig-loader and template-resolution approach, then implement it as an internal service in our own app against a current PhpSpreadsheet version. If we need PDF, wire mPDF or a headless browser instead. If we ever do need this exact package, pin it, vendor it, and add it to the dependency-review list rather than pulling it from Packagist at deploy time.
• Also flag the mismatch: this is a Symfony bundle and our stack is [Laravel/PHP], so integration cost is non-trivial and the value is purely as a reference implementation.