mattfanz/twig-spreadsheet-bundle
A Symfony bundle that brings spreadsheet generation into Twig templates, letting you build and render Excel-style documents directly from your views with minimal PHP boilerplate. Useful for exports, reports, and downloadable data files.
Architecture fit. This is a Symfony bundle, not a Laravel package. It registers a service provider through Symfony's Bundle class convention and exposes spreadsheet generation as Twig-powered response objects (SpreadsheetResponse, SpreadsheetObjectResponse), typically wired through a controller return value. Laravel's service container, package discovery (extra.laravel.providers), and HTTP response lifecycle are structurally different. There is no Laravel service provider, no facade, no config publishing — integrating it means treating it as a plain Composer dependency and manually reimplementing the bundle's registration surface. The core value (PhpSpreadsheet + Twig templating of cells) is portable; the Symfony glue is not.
Integration feasibility. Partial. If the team's stack is genuinely Symfony, feasibility is high and the package does roughly what it says. If the stack is Laravel — which the framing implies — feasibility is moderate at best: you would install phpoffice/phpspreadsheet and reproduce the templating layer yourself, at which point this package contributes little beyond reference implementation. The dependency risk sits in the fork: 1 star, 0 dependents, and a version score of 0.005 indicate essentially no adoption signal, no ecosystem validation, and no downstream pressure to keep it current with PhpSpreadsheet majors.
Technical risk. High, concentrated in three places. (1) Provenance: this appears to be a low-activity fork of a pre-existing TwigSpreadsheetBundle lineage; forks of forks drift from upstream security patches and PhpSpreadsheet API changes without anyone noticing. (2) Abandonment: 0 dependents means no one will file the bug you hit, and no one will fix it. (3) Upgrade coupling: PhpSpreadsheet has made breaking changes across majors (writer APIs, cell coordinate handling, memory settings); a package with no traffic is unlikely to have tracked them. The realistic worst case is not a crash on day one but a silent breakage on a composer update three quarters in.
Key questions.
Stack fit. Poor-to-conditional for Laravel. There is no illuminate/support contract satisfied, no auto-discovery, and the response classes extend Symfony's Response. A Laravel integration requires: binding the bundle's services into Laravel's container, replacing the Symfony response with a Symfony\Component\HttpFoundation\StreamedResponse-compatible return or a Laravel Response wrapping the writer output, and hand-rolling configuration. Each of those is small, but together they constitute a thin adapter layer that we would own forever.
Migration path. Two viable paths, in preference order.
phpoffice/phpspreadsheet directly. Implement a small internal SpreadsheetRenderer service that loads a Twig template, walks a defined cell map, and returns a streamed download. This is on the order of a few days, has a single well-maintained dependency, and preserves the templating ergonomics that motivated the package. Recommended.A third path — vendoring the fork and patching it — is defensible only if there is a hard requirement to preserve existing Twig spreadsheet templates from an inherited Symfony codebase. Even then, scope the vendoring to the templating extension, not the bundle plumbing.
Compatibility. Verify the PhpSpreadsheet constraint resolves against the project's PHP version and any transitive psr/* or symfony/* constraints. Because the package has effectively no dependents, expect the constraint to be either very loose (risking future breaks) or pinned to an old major (blocking other libraries). Run composer why-not against PhpSpreadsheet before committing. Also check whether the bundle's Twig extension targets Twig 2 or 3 — Twig 3 removed several APIs and low-traffic bundles frequently lag.
Sequencing. If pursuing path 1: (a) spike a single Xlsx export end-to-end in a day to confirm writer output and memory behavior on a realistic row count; (b) build the renderer service and a template contract; (c) migrate exports one at a time behind feature flags; (d) only then remove any inherited bundle code. If pursuing path 2, gate adoption on a written confirmation that the host is Symfony and that the PhpSpreadsheet constraint matches, plus a scheduled review of the fork's upstream at each major PhpSpreadsheet release.
Maintenance. Effectively unmaintained upstream. Budget for the package being ours the moment we adopt it: security patches to PhpSpreadsheet, Twig API migrations, and PHP version bumps all land on our team. This is the dominant cost and it is not visible in the dependency's size or license (MIT is permissive but confers no support obligation). The direct-PhpSpreadsheet path reduces this to tracking one actively maintained library.
Support. No vendor, no community of scale, no issue history to search. Internal escalations route to whoever wrote the integration. For a single-team internal tool this is acceptable; for anything customer-facing or revenue-adjacent it is a gap.
Scaling. Spreadsheet generation is memory- and CPU-bound on the application tier, not a scaling concern of the bundle per se, but the bundle's response model (building the full workbook in memory before streaming) is the common failure pattern. Large exports — tens of thousands of rows — will pressure PHP's memory_limit and worker concurrency. Mitigations are PhpSpreadsheet-level: --use-write-only style caching, chunked writers, or offloading to a queue with object storage and a signed URL. Plan exports as asynchronous jobs rather than synchronous request handlers, and set explicit row ceilings. PDF output is markedly more expensive than Xlsx and should be treated as a separate capacity line.
Failure modes. Ranked by likelihood: (1) silent breakage on a transitive composer update, mitigated by pinning exact versions and a CI test that generates and validates a fixture workbook; (2) memory exhaustion on large exports, mitigated by row caps and async offload; (3) Twig template drift — a template edited by a non-engineer produces a malformed or empty sheet with no error, mitigated by schema validation of the cell map; (4) abandoned-package lock-in where an eventual PHP or PhpSpreadsheet upgrade is blocked by the package's constraint, mitigated by keeping the integration thin enough to swap. A single integration test that asserts cell values, not just HTTP 200, catches most of these cheaply.
Ramp-up. Low technical learning curve — the bundle's API surface is small and Twig templating for cells is intuitive. The real ramp-up cost is organizational: establishing ownership, writing the adapter or renderer, and building the test fixture that makes the dependency survivable. Estimate one engineer, roughly one to two weeks for the direct-PhpSpreadsheet path including tests; the Symfony-bundle path is faster to first output but carries a materially higher ongoing tax.
Recommendation. Do not adopt this package for a Laravel codebase. Adopt phpoffice/phpspreadsheet directly and build the thin Twig templating layer in-house, or use a maintained Laravel-native export package if template-driven authoring is not actually a requirement. Reserve this bundle for genuine Symfony hosts with an inherited template corpus, and in that case treat it as vendored code with an internal owner rather than as an external dependency.
How can I help you explore Laravel packages today?