Twig Spreadsheet Bundle Laravel Package

Product Decisions This Supports

• Feature scoping — "Excel export" vs. CSV-only. Spreadsheet output is a recurring request in B2B admin/reporting surfaces (finance packs, ops reports, downloadable data grids). This package represents the "Twig-templated .xlsx" pattern: business users own a template file with placeholders, the app renders it. That's a meaningfully different feature than raw CSV export (formatting, multi-sheet, formulas, print layouts) and should be priced/prioritized separately on the roadmap.
• Build vs. buy for the glue layer. PhpSpreadsheet (MIT) is the real engine and is well-maintained; this bundle is a thin Symfony/Twig adapter around it (~1 star, 0 dependents, no community validation). The actionable decision this informs is not "adopt this bundle" but "adopt PhpSpreadsheet and build a small in-house Twig-to-cell adapter," using this repo as a reference implementation. Typical effort: 1–2 sprints for a first templated-report slice.
• Customer-facing templating as a differentiator. If your buyers are ops/finance teams who maintain their own report layouts, "upload your .xlsx template, we fill it" is a sellable capability. If the need is one-off internal exports, it's commodity and CSV/streamed download is enough. This package's pattern helps you decide which of those two you're building.
• Bulk import/data-ingestion roadmap. The same PhpSpreadsheet integration covers the inbound direction (reading uploaded workbooks), so a decision here can unlock a second feature line (bulk onboarding, data migration imports) at marginal engine cost.
• Supply-chain / dependency policy decision. A 1-star, 0-dependent bundle is a governance data point: it sets precedent for whether the org accepts single-maintainer, unvetted dependencies for revenue-adjacent features. That's a policy call the PM should force, not let engineering make implicitly.

When to Consider This Package

• Consider it (as a reference, not a dependency) when: you are on Symfony + Twig, you need .xlsx output whose layout is owned by business users, and you want a concrete pattern for placeholder replacement, cell styling, and multi-sheet rendering rather than designing it from scratch. Copy the approach; vendor or fork the code if you must ship fast.
• Hard pre-checks before any adoption: confirm the bundle's composer.json constraints against your Symfony version (bundles of this vintage typically predate Symfony 6/7), your PhpSpreadsheet major version, and your PHP version. Also confirm whether Twig templating of cells is actually what you need versus Twig rendering of a full HTML/CSV body.
• Look elsewhere / build in-house when: you need active maintenance and security patching (this has no release cadence and one maintainer); you are on modern Symfony; you need large-export streaming (PhpSpreadsheet is memory-hungry — the bundle adds no mitigation); you need CSV/PDF only; you're not on Symfony/Twig; or you have audit/compliance requirements that a 0-dependent package cannot satisfy.
• Do not consider it as a long-lived runtime dependency for a revenue-critical path without forking, pinning, adding tests, and assigning an internal owner — at 1 star and 0 dependents there is no community backstop if the maintainer disappears or a CVE lands in the adapter.
• Also look elsewhere if your real need is spreadsheet reading/validation at scale (schema-checked imports), where dedicated import libraries or a managed service are a better fit than a rendering-oriented bundle.

How to Pitch It (Stakeholders)

• To executives: "Customers are asking for formatted Excel reports, not just CSV. The underlying engine (PhpSpreadsheet) is mature, MIT-licensed, and free. There's a niche Symfony bundle that demonstrates the Twig-template pattern, but it's a single-maintainer package with effectively no adoption — so I'm recommending we take the pattern and own a small (~1–2 sprint) adapter in-house. Same customer outcome, no third-party supply-chain exposure on a customer-facing feature."
• To engineering: "Treat mattfanz/twig-spreadsheet-bundle as a design reference, not a dependency. It shows how to map Twig placeholders onto PhpSpreadsheet cells and preserve template formatting; we can reimplement the ~few hundred lines we need against our current Symfony/PhpSpreadsheet versions, with tests and an owner. If we do pull it in short-term, pin it, vendor it, and plan to replace it before GA."
• Framing the ask: low cost, low risk, modest scope — decision needed is which direction (templated .xlsx vs. plain CSV) and who owns the adapter, not approval of a new vendor relationship.

Recommendation: reject as a production dependency; adopt PhpSpreadsheet and reuse this repo's pattern internally.