- Does mattfanz/twig-spreadsheet-bundle work with Laravel?
- Not natively. It is a Symfony bundle that registers itself through Symfony's Bundle class convention and returns SpreadsheetResponse or SpreadsheetObjectResponse objects that extend Symfony's Response, so there is no Laravel service provider, facade, auto-discovery entry, or publishable config. You can install it as a plain Composer dependency, but you would need to hand-wire its services into Laravel's container and replace the Symfony responses yourself. Fit is partial at best; the portable part is PhpSpreadsheet plus Twig cell templating, not the Symfony glue.
- How do I install mattfanz/twig-spreadsheet-bundle?
- Run composer require mattfanz/twig-spreadsheet-bundle. In a Symfony application you then register the bundle in config/bundles.php and import its configuration; in Laravel there is nothing to register automatically, so you would bind the services manually and wrap the writer output in a Laravel response. Before installing anywhere, check the adoption signal: the package has roughly one star, zero dependents, and a very low version score, which means essentially no ecosystem validation.
- Which PhpSpreadsheet and PHP versions does this bundle support?
- The bundle's PhpSpreadsheet major is pinned by its composer.json constraint, so read that file before assuming compatibility with the rest of your stack. PhpSpreadsheet has shipped breaking changes across majors in writer APIs, cell coordinate handling, and memory settings, and a low-traffic fork is unlikely to have tracked them. If the pinned major does not match what your other packages need, expect a dependency conflict or a runtime surprise on composer update.
- Is TwigSpreadsheetBundle maintained, and is this fork safe to depend on?
- This package appears to be a low-activity fork of a pre-existing TwigSpreadsheetBundle lineage, which matters because forks drift from upstream security patches and API changes without anyone noticing. With one star and zero dependents there is no downstream pressure to keep it current. Establish which upstream project it forks from and whether that upstream is maintained, since forking a live project is a very different risk profile from forking a dead one.
- How do I return a spreadsheet download from a Laravel controller?
- You cannot return the bundle's response objects directly, because Laravel expects an Illuminate response or a Symfony HttpFoundation response it can wrap. The practical approach is to let the bundle or PhpSpreadsheet build the workbook, then stream the writer output through response()->streamDownload with the correct content type and filename. That conversion code is small, but it is an adapter layer your team owns forever.
- Should I use this bundle or phpoffice/phpspreadsheet directly in Laravel?
- For a Laravel codebase, going straight to phpoffice/phpspreadsheet and writing a small internal renderer that loads a template and walks a defined cell map is the recommended path. It is on the order of a few days of work, leaves you with a single well-maintained dependency, and preserves the templating ergonomics that motivated the package in the first place. Adopt the bundle as-is only if the host application is genuinely Symfony.
- Can TwigSpreadsheetBundle export PDF and CSV, or only Xlsx?
- It delegates to PhpSpreadsheet writers, so you get whichever writers your pinned PhpSpreadsheet version provides, typically Xlsx and Csv, with Pdf available if a renderer such as Dompdf or Mpdf is installed. Pdf is the most fragile surface because it drags in that extra renderer dependency. Whichever writers you actually ship, add a smoke test against real output rather than trusting the package to keep working.
- How do I test spreadsheet generation with this package?
- Write one smoke test per writer: build the spreadsheet from your Twig template, assert the response content type and filename, and verify the downloaded bytes open as a valid file. Because the package has no maintenance pressure, pinning the generated output in a test is your only early warning against silent breakage on a composer update. Keep assertions focused on your cell map and template, not on the bundle's internals.
- Who maintains this package, and what happens if it is abandoned?
- There is effectively no maintainer community around it: one star and zero dependents means no one will file the bug you hit and no one will fix it. The realistic worst case is not a crash on day one but a silent breakage on a composer update a few quarters in. Before adopting it, decide who owns it internally and whether you are prepared to vendor or fork it yourselves.
- What is the Laravel alternative to TwigSpreadsheetBundle for spreadsheet exports?
- The common choice is phpoffice/phpspreadsheet directly, usually behind a small service class your team controls, or a Laravel-native wrapper such as maatwebsite/excel that adds export classes, queued exports, and testing helpers. If the requirement is genuinely template-driven, meaning non-engineers author layouts in Twig or Blade, a templating layer can justify itself. If it is a one-off export, the dependency does not.