Twig Excel Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy on the export layer. The package's core idea — a Twig template that renders directly to .xlsx, so non-engineers (ops, finance) can own the layout of a report while engineers own the data binding — is a genuine product decision worth making. This package is evidence the pattern is desirable; it is not itself the answer.
• Feature scoping for "Export to Excel." Most roadmaps treat export as one ticket. This repo shows the useful split: (a) raw data dump, (b) cell-level formatting, (c) branded/templated workbook with formulas and merged cells, (d) scheduled delivery. Only (c) justifies a templating abstraction; (a) and (b) are a weekend of PhpSpreadsheet.
• Roadmap investment in a reporting surface. If Excel output is a differentiator (board packs, invoices, reconciliation workbooks, regulatory filings), the decision is to fund a first-class exporter service with fixture tests and golden-file snapshots — not to wire a bundle into controllers.
• Buy-vs-fork signal for the ecosystem. Zero dependents on a 37-star Symfony bundle is a data point about ecosystem gravity: templated spreadsheet generation lives inside umbrella packages (Laravel Excel, Symfony's PhpSpreadsheet bridges) rather than standalone bundles. That argues for consolidating on the umbrella package your framework already favors.
• Platform coherence check. This is a Symfony bundle. If the product is Laravel, adopting it is an immediate architectural mismatch — a decision to not widen the framework surface area, which is often the more valuable call.

When to Consider This Package

Adoption criteria — all of these must be true, and in practice the fourth will fail:

1. The application is Symfony, not Laravel, and you accept its bundle/service-tag conventions.
2. You specifically want template-driven spreadsheet output (Twig → xlsx) rather than programmatic writer calls.
3. You are still on PHPExcel — or willing to fund a port to PhpSpreadsheet, since PHPExcel was deprecated and archived in 2019 and receives no security or PHP-version maintenance.
4. You accept an archived, single-maintainer dependency with no dependents — meaning you are effectively forking it on day one, owning patches, and testing every PHP and PhpSpreadsheet upgrade yourself.

Reality check: even in a Symfony shop, condition 3 or 4 usually kills it.

Look elsewhere when:

• You're on Laravel (the common case): use maatwebsite/excel — it has the Blade/export-view templating, queued exports, chunked reads, and an active maintainer base. This is a straight substitution, not a workaround.
• You need throughput, not formatting: openspout/openspout streams rows with constant memory for large exports where the browser or queue worker would otherwise OOM.
• You need a real template engine for workbooks: generate via PhpSpreadsheet against a pre-built .xlsx skeleton checked into your repo, load it, fill named ranges, and save. Keeps the layout in a file the business can edit; keeps the code testable.
• You need multi-format or scheduled reporting: a reporting service or BI tool (Metabase, Looker, a small Python worker) is cheaper than owning an export engine.
• You want zero supply-chain risk: anything archived, unmaintained, or on PHPExcel is disqualifying for regulated or long-lived products.

How to Pitch It (Stakeholders)

Recommendation: do not adopt. Adopt the pattern, not the package.

For executives: We evaluated an open-source library for generating formatted Excel reports from templates. It solves a real user need — letting finance and ops shape their own report layouts — but it is built on PHPExcel, which has been end-of-life since 2019, the repository is archived, and nothing else in the ecosystem depends on it. Using it would mean we inherit maintenance for a component with no upstream support. Estimated cost of ownership outweighs a few weeks of build.

For engineering: The concept is sound — Twig (or Blade) template → xlsx — and the repo is worth reading as a design reference for how to map template constructs onto workbook cells, styles, and formulas. The implementation is not viable: Symfony-only, PHPExcel-bound, unmaintained, zero dependents, single author, archived.

The ask: Approve roughly one sprint to build a thin export module on maatwebsite/excel (Laravel) or PhpSpreadsheet + a checked-in .xlsx template (Symfony), guarded by golden-file tests so layout regressions are caught in CI. This gives us the same capability with an actively maintained dependency, lets the business edit layouts without a deploy, and avoids a fork-from-day-one liability.

Risk if we defer: Low. maatwebsite/excel and PhpSpreadsheet already cover this; the only thing we'd lose is the template-abstraction convenience, which is exactly the part worth building ourselves.