Twig Excel Bundle Laravel Package

Technical Evaluation

Architecture fit — poor, but not for the reason the description implies. mewesk/twig-excel-bundle is a Symfony bundle, not a Laravel package. It ships a Bundle subclass registered through AppKernel/bundles.php, publishes services via Symfony DI YAML/XML, and registers its Twig extension through the twig.extension service tag. Laravel has no equivalent runtime for BundleInterface, no service tagging semantics, and no kernel-based bundle discovery. The only genuinely reusable asset is the Twig extension class itself — a thin wrapper that maps a template render to a PHPExcel_Writer_* call. Everything around it is Symfony-shaped and would be discarded.

Second, larger problem: the transitive dependency is dead. The bundle is built on PHPExcel, which was deprecated in favour of PhpSpreadsheet and has had no release since 2015. PHPExcel does not run cleanly on PHP 7.2+ (deprecation-level failures) and breaks outright on PHP 8.x. Any Laravel application on a supported PHP version cannot install this dependency graph without a fork. The repository is archived, has 37 stars and zero dependents, meaning no downstream project is exercising the code path and no one is filing or fixing issues.

Integration feasibility. Viable only as an extraction exercise, not an installation:

• Lift the Twig extension (roughly one class plus a token-parser helper for the {% excel %}-style tags) into app/Support.
• Re-point every PHPExcel_* call at the PhpSpreadsheet equivalents (PhpOffice\PhpSpreadsheet\Writer\Xlsx, IOFactory).
• Register the extension against whichever Twig environment the Laravel app uses (rcrowe/twigbridge or a manually bound Twig\Environment).
• Skip the bundle's DI config, composer type: symfony-bundle metadata, and any Symfony-version constraints entirely.

That is a half-day to two-day spike for a developer fluent in both Twig and PhpSpreadsheet, and it produces a first-party class you own rather than a dependency you inherit.

Technical risk — high. Archived source, EOL spreadsheet engine, no security response path, PHP 8 incompatibility, and zero field validation from dependents. The opportunity score of 4.96 reflects a real, underserved problem space (server-side spreadsheet templating from a view layer), not the quality of this artifact.

Key questions before any decision:

1. Is the target application actually Laravel, or is this assessment scoped against a Symfony service where the bundle is at least structurally correct?
2. What is the concrete requirement — xlsx templating (placeholder substitution into a pre-built workbook), or plain tabular export? The former justifies Twig; the latter does not.
3. What PHP version and framework major must be supported? Anything ≥ 8.0 eliminates PHPExcel outright.
4. Is there an existing workbook template asset that must be preserved bit-for-bit (styles, merged cells, charts), or can output be regenerated?
5. What are the size bounds — rows × columns per export, and concurrent exports per minute?

Integration Approach

Stack fit. For a Laravel codebase: do not composer require this package. For a Symfony 2.x/3.x codebase: the bundle is structurally correct but the PHPExcel floor still caps you at an unsupported PHP runtime, so the same fork-and-modernise work applies.

Recommended path — adopt the pattern, not the package. Reimplement the Twig-to-spreadsheet bridge on PhpSpreadsheet, which is actively maintained, PHP 8 compatible, and supports the same template-load-then-write workflow (IOFactory::load($template) → set cell values → new Xlsx($spreadsheet) → save()). This preserves the bundle's core value proposition — designers edit a real spreadsheet template, developers render it from a view — without inheriting the dead dependency.

Alternatives worth benchmarking in the same spike:

• maatwebsite/excel (Laravel Excel) — Blade-based export views, PhpSpreadsheet underneath, active ecosystem. Closest analogue to the Twig-templating idea and the natural default for a Laravel stack.
• openspout/openspout (successor to box/spout) — streaming writer, dramatically lower memory, but no template/style preservation.
• Raw PhpSpreadsheet with a hand-rolled Twig function — maximum control, minimal dependency surface.

Compatibility notes if forking. Expect Twig 1.x-era extension APIs (pre-AbstractExtension interfaces), Symfony 2/3 service definitions, and PHPExcel's underscore-separated class names throughout. Budget for a mechanical rename pass (PHPExcel_ → PhpOffice\PhpSpreadsheet\) plus targeted fixes where method signatures changed — writer constructors, setCellValue behaviour, and style array keys are the usual break points.

Sequencing.

1. Confirm stack and PHP floor (answers the key questions above).
2. Timebox a one-day spike: fork the extension, port to PhpSpreadsheet, render one real template.
3. Benchmark against Laravel Excel on the actual template asset — style fidelity, memory, and time.
4. Decide build vs. adopt, then harden: formula-injection guards, memory limits, and a queued-export path for anything large.
5. Only if the spike fails and the Symfony path is confirmed, revisit the bundle as-is.

Operational Impact

Maintenance. Effectively infinite and entirely yours. The upstream is archived, so there is no path to a patch — every future PHP minor, every Twig major, and every CVE touching the spreadsheet engine becomes your ticket. Adopting the package means inheriting PHPExcel's unpatched vulnerability surface and owning the Symfony-to-Laravel port. Adopting the pattern on PhpSpreadsheet means a normal, upgradable dependency with an active maintainer.

Support. No community to lean on: 37 stars and zero dependents means no Stack Overflow corpus, no issue history worth reading, and no third party who has hit your bug. Onboarding documentation is the README alone. PhpSpreadsheet and Laravel Excel, by contrast, have substantial documentation and answerable search results.

Scaling. PHPExcel's object-per-cell model is memory-hungry — roughly a kilobyte or more per populated cell once style and formula objects are counted — so a 100k-row export can push past default memory_limit and produce an opaque fatal rather than a clean error. There is no streaming writer in this bundle. If export volume is non-trivial, this is disqualifying on its own; route through PhpSpreadsheet with cell caching enabled, or through OpenSpout for pure tabular output, and push generation to a queue with the file handed back via signed URL.

Failure modes to design against.

• Fatal on PHP 8 from legacy PHPExcel internals — surfaces at runtime, not install time, if constraints are loose.
• Memory exhaustion on large sheets, presenting as a 500 with no useful signal.
• Silent style loss when a template round-trips through an incompatible writer version.
• Twig autoescaping interfering with cell content, or the inverse — unescaped user input written into cells beginning with =, +, -, or @, producing CSV/XLSX formula injection in files opened by downstream users.
• Unpatched transitive CVEs in the archived dependency chain that no scanner will flag as fixable.

Ramp-up. Low for a Symfony developer — the bundle's surface is small and the Twig-tag pattern is intuitive. Moderate for a Laravel team, because the mental model (bundle registration, service tags) has no direct analogue and the fork requires reading Symfony-era code. Either way, the spreadsheet ramp-up — template placeholders, style preservation, memory behaviour — dominates and is identical across all four options, which is the strongest argument for choosing the maintained library and not paying the port cost twice.

Bottom line. Do not adopt. The package is archived, the engine beneath it is end-of-life, it targets the wrong framework, and it has no dependents to validate it. Extract the templating idea, implement it on PhpSpreadsheet or Laravel Excel, and treat this repository as a design reference at most — which is roughly the value its 37 stars and 4.96 opportunity score imply.