Twig Spreadsheet Bundle Laravel Package

Technical Evaluation

Architecture fit — poor, with a naming trap. Despite the request framing, this is not a Laravel package. mewesk/twig-spreadsheet-bundle is a Symfony bundle: it registers a DI extension, a spreadsheet service, and a Twig extension that exposes spreadsheet primitives (sheets, cells, styles, writers, response factory) as Twig functions/filters. Laravel has no bundle kernel, no Extension/CompilerPass hook, and no Twig as its default view engine. The value proposition — authoring spreadsheet layouts in a template rather than in PHP — is real and demonstrably useful for report-heavy products, but it is delivered through a Symfony-shaped integration we would have to rebuild.

Integration feasibility. Direct composer require will fail or require --ignore-platform-reqs: the 2018 release line targets PHP 7.x, Symfony 3.4/4.x, Twig 1/2, and early PhpSpreadsheet ^1.0. A modern Laravel (10/11, PHP 8.2/8.3) runs PhpSpreadsheet ^2/^3/^4. Two viable paths:

1. Fork-and-rewire (high effort, ~medium value): pull in rcrowe/twigbridge so Twig exists in Laravel, then reimplement the bundle's service definitions as a Laravel service provider, re-register the Twig extension, and re-target the PhpSpreadsheet API surface (writer/response APIs changed materially since 1.0).
2. Reimplement the pattern natively (medium effort, higher value): treat the bundle as a reference design and build a Laravel-native exporter — PhpSpreadsheet directly, with a Blade-based or array-spec-based layout layer — or adopt maatwebsite/excel, which is actively maintained and Blade-friendly.
3. Use as-is (not recommended): only defensible on a legacy PHP 7.2/Symfony 4 sidecar service.

Technical risk. High and concentrated in abandonment: archived repo, last release 2018-07-29, 22 stars, 0 dependents, no security-response path. Abandoned code that ingests/emits .xlsx sits on a parser with a real CVE history (XML external entity handling, zip/stream handling, formula injection in generated files). Pin-and-freeze is not a mitigation for a file-format parser. Secondary risks: API drift against modern PhpSpreadsheet, no PHP 8.3 typing guarantees, no Laravel queue/streamed-response idioms, and an implicit "Twig sandbox" question if template content is ever user-influenced.

Key questions for the team.

• Do we actually need template-authored spreadsheets, or is a fluent PHP builder sufficient? (Most Laravel teams discover the latter.)
• Is Twig-in-Laravel acceptable as a permanent second view engine, or a one-way migration crutch?
• What is the true inventory of existing report templates, and are any business-critical or compliance-bound (finance, regulatory filings)?
• Which PhpSpreadsheet major do we standardize on, and who owns upgrades?
• Is the archive status acceptable for an export path that produces customer- or regulator-facing artifacts? (Default answer: no.)
• Does the opportunity score (6.9) reflect a real underserved niche — Twig-style declarative spreadsheet layout — that we could capture by building our own DSL, rather than by resurrecting this bundle?

Integration Approach

Stack fit. Misaligned at every layer: Symfony bundle → Laravel service provider; Twig → Blade; PHP 7.x → PHP 8.2+; PhpSpreadsheet ^1.0 → ^2/^3. Only the license (MIT) and the underlying engine (PhpSpreadsheet) fit cleanly.

Migration path (recommended, capability-first).

1. Capability inventory (1–2 days): enumerate the spreadsheet features actually used — multi-sheet, named ranges, styling, merged cells, formulas, column sizing, writer choice, HTTP response delivery. The bundle's surface is broad; real usage is usually narrow.
2. Golden-file harness: capture current outputs as byte-comparable or cell-by-cell comparable fixtures. This is the acceptance gate for everything downstream and is the single highest-leverage TPM artifact here.
3. Prototype native exporter (1–2 weeks): PhpSpreadsheet service class + layout spec (array/PHP config or Blade partial) covering the inventoried features. Compare against golden files.
4. Optional Twig bridge (only if template authoring is a hard requirement): add rcrowe/twigbridge and a SpreadsheetServiceProvider that mirrors the bundle's extension registration. Isolate behind a feature flag; do not let Twig reach business logic.
5. Cutover and removal: delete the archived dependency, delete Twig if it exists only for this, document the DSL.

Compatibility notes. If a fork is unavoidable, fork under our org, bump constraints to PHP ^8.2 / PhpSpreadsheet ^2|^3 / Twig ^3, drop Symfony DI in favor of a Laravel provider, and pin with a maintained-branch policy. Budget 3–5 days for the fork to boot, plus ongoing ownership.

Sequencing. Pilot on the lowest-risk, highest-visibility report first (one exporter, one golden-file suite). Prove parity before touching finance/regulatory outputs. Run both paths in parallel for one release cycle behind a config flag, then retire. Do not start with the largest workbook — PhpSpreadsheet memory profile will confound the comparison.

Operational Impact

Maintenance. Zero upstream. No patches, no PHP minor-version support, no PhpSpreadsheet security advisories reaching us. Every fix becomes internal engineering time; every transitive CVE becomes an internal triage event with no vendor to lean on. Contrast with maatwebsite/excel or direct PhpSpreadsheet, both actively released.

Support. No community, no issue triage, 22 stars and zero dependents means effectively no peer base to search for answers. Support cost lands entirely on the owning squad; expect Twig + Symfony DI literacy to be a prerequisite for anyone touching it, which narrows the on-call pool.

Scaling. PhpSpreadsheet is memory-bound, not CPU-bound. Large workbooks routinely exhaust PHP memory limits and are unsuitable inline in a request. The bundle predates Laravel's queue and streamed-download idioms, so we get none of the "dispatch a job, stream the result" ergonomics for free — we would build that ourselves regardless. Plan for job-based generation, temp-disk spooling, and chunked writers for anything over a few thousand rows.

Failure modes.

• Memory exhaustion / request timeout on large exports; manifests as 500s late in the request, hard to reproduce.
• Formula injection in generated files if any cell value is user-supplied — a security issue, not a cosmetic one.
• Parser CVEs in an unpatchable dependency.
• Silent layout regressions after any PhpSpreadsheet touch; the golden-file harness is the only real guard.
• Dependency-resolution deadlock at the next Laravel or PHP upgrade, blocking platform work for unrelated reasons.
• Bus-factor one on whoever understood the Twig DSL.

Ramp-up. Expect 3–5 days for a mid-level engineer to be productive in the bundle's template idioms, plus 1–2 days for the Symfony DI/extension wiring, plus Twig onboarding if absent. That is a real cost paid against an abandoned dependency — a poor return when a native exporter is roughly the same ramp with a maintained engine underneath.

TPM recommendation. Do not adopt as a runtime dependency. Adopt as a design reference: the declarative, template-driven spreadsheet layout idea is the genuinely interesting part, and the 6.9 opportunity score plausibly reflects that niche. Capture it by building a thin Laravel-native layout layer over current PhpSpreadsheet (or Laravel Excel), gated by golden-file parity tests, and close the archive risk out entirely on a 3–4 week horizon.