Twig Spreadsheet Bundle Laravel Package

Product Decisions This Supports

• Whether to build a "template-driven export" capability at all. This bundle is the proof of concept: non-developers (ops, finance, customer success) can own the look of an .xlsx deliverable by editing a Twig-templated spreadsheet, while engineering only supplies the data array. If your roadmap has repeated "can we change the columns/formatting on the monthly report?" tickets, that's the signal this pattern solves.
• Build vs. buy for reporting/export. Not a buy decision — the package is MIT and free — but a build vs. depend decision. It answers "how much bespoke code does a spreadsheet renderer cost?" with a concrete reference implementation: a Twig extension plus a PhpSpreadsheet writer, roughly a few hundred lines. Useful as a sizing input for a spike.
• Framework stack alignment. Important correction for planning: this is a Symfony bundle, not a Laravel package. There is no service provider, no facade, no config publishing. Adopting it means committing to Symfony's bundle registration model, or budgeting adapter work to wrap it for a Laravel app. That alone can flip a "cheap dependency" into a "small internal library."
• Risk/roadmap signal on small dependencies — and on how to read "abandoned." The 1.1 release is the first sign of life since 2018-07-29, and it materially changes the dependency-review verdict from archived/do-not-use to low-activity but alive. It fixes real correctness bugs (image cache directory resolution, a pre_calculate_formulas bug, style-merge behaviour where non-array values were merged instead of overriding) and adds capability (see below). For a tech-radar or dependency-review exercise, this is a good teaching case: "abandoned" is a point-in-time observation, not a permanent property — re-check archive status, open-issue responsiveness, and supported upstream versions on every review cycle rather than restating a stale verdict.
• Feature-level scoping for exports. The Twig-over-spreadsheet model defines a clean separation of concerns worth copying regardless of adoption: data shaping (backend), presentation (template), rendering (PhpSpreadsheet). Use that split as the acceptance criteria for your own export stories. Release 1.1 sharpens two of these seams:
  • xlscellindex / xlsrowindex expose the current render position to the template — this is what makes alternating row styling, conditional per-row footers, and "start writing here" layout regions possible without hard-coding offsets. Any template-driven export design we own should have an equivalent.
  • Advanced CSV writer configuration (custom delimiters/separators, etc.) confirms that CSV is an explicit output target rather than a degraded .xlsx. Useful evidence that "give me this in Excel" and "give me a CSV my ERP can ingest" are the same product surface with different writers, not two epics.
• Use cases it legitimizes: scheduled finance/ops report exports, customer-facing data dumps where the customer wants their own formatting, invoice/statement generation, bulk-import template scaffolding (the reverse direction), and internal "give me this in Excel" requests.

When to Consider This Package

Consider the pattern (or a fork) when:

• You are on Symfony and already use Twig heavily, so the mental model and rendering pipeline are free.
• The deliverable's layout changes more often than its data contract — i.e., stakeholders iterate on formatting, not on the underlying query.
• You need position-aware templates (banded rows, per-row subtotals, region-based fill). The new xlscellindex / xlsrowindex functions are the minimum viable API for this, and they are now present.
• You need both .xlsx and configured CSV from one template definition — 1.1's CSV writer options remove what used to be a two-pipeline design.
• You want a fast spike (days, not a sprint) to validate demand for self-serve report templates.
• You're comfortable treating the code as a starting reference, forking it, and owning maintenance internally.

Look elsewhere — or build directly on PhpSpreadsheet — when:

• You're on Laravel. There is still no integration path here; use maatwebsite/excel with Blade views (same idea, maintained, Laravel-native) or write a thin PhpSpreadsheet wrapper. Release 1.1 does nothing to change this — it adds template functions and writer options, not a Laravel bridge.
• You need anything production-critical and you have not re-verified maintenance health. A single release after a multi-year gap is evidence of activity, not a track record. Before depending: confirm the repo is un-archived, confirm which PhpSpreadsheet major and PHP versions 1.1 actually supports (the release notes advertise performance and index-handling improvements but make no dependency or PHP-version claim), and confirm someone is triaging issues. Expect the historical version-pin and PHP-8 compatibility risk to persist until that's demonstrated.
• Untrusted users will author templates. Twig template execution over user-supplied content is a sandboxing/security decision, not a feature toggle. Plan for a restricted function set or a non-executable template DSL — and note that the new index functions are additional surface to allow-list.
• You need large exports (hundreds of thousands of rows). PhpSpreadsheet is memory-hungry; streaming writers (openspout) or CSV-first is the better call. 1.1's "improved performance" is not a streaming story, and its CSV improvements are about format configuration, not throughput.
• You need charts, pivot tables, or fidelity to a designer-authored workbook. Template-driven cell writing won't reproduce complex native Excel artifacts reliably. The style-merge fix in 1.1 is a reminder that the package writes cells and styles, not document structure.
• You want managed output (scheduling, delivery, template versioning, audit). A reporting SaaS or your own job + storage layer is the real product; the renderer is the smallest part.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed open-source library that demonstrates a genuinely useful idea — letting the business own the formatting of Excel and CSV reports instead of filing engineering tickets for every column change. Our prior read was "archived, avoid." That has changed: a 1.1 release has landed with real bug fixes (image caching, formula pre-calculation, style overrides) and modest new features (position helpers in templates, configurable CSV output). We still do not recommend taking a dependency today, for two unchanged reasons: it is Symfony-only while our stack is Laravel, and one release after a multi-year gap is not yet a maintenance track record. There's no license cost either way; the question is only whether we carry the maintenance and security risk ourselves.

To engineering: The verdict moves from "do not adopt, treat as reference" to "still do not adopt, but re-open the re-evaluation checkbox and treat it as a live reference." Two things changed that are worth copying into whatever we build:

1. Template-visible position (xlscellindex, xlsrowindex) — this, not cell writing, is what makes banded rows and region-based layouts feasible in a template DSL.
2. Writer configurability — one template, multiple serializers (.xlsx, delimited CSV with custom separators). Design the writer as an interface from day one.

Unchanged: an internal fork is still a two-to-three week build (template format, sandboxed render path, versioning, queue for large exports). Before anyone proposes adopting upstream, require a check of its un-archived status, supported PhpSpreadsheet/PHP matrix, and issue triage cadence — the release notes make no dependency claims, so the historical PHP-8 and version-pin risk is unproven either way.

Recommendation: Do not adopt — unchanged — but downgrade the risk framing from "abandoned" to "low-activity, intermittently maintained." Keep building on maintained components (PhpSpreadsheet or a streaming writer, with Blade on Laravel), and carry the two 1.1 ideas — position-aware templates and pluggable writers — into that design. Re-check the upstream repo at the next dependency review; if a second and third release follow with current PhpSpreadsheet/PHP support, this becomes a legitimate fork candidate even for a Laravel shop. It remains a same-day prototype option only if we move to Symfony.