Excel Bundle Laravel Package

Technical Evaluation

Architecture fit. Poor. fungio/excel-bundle is a Symfony2 bundle, not a Laravel package. Its value-add over the underlying library is Symfony-specific: bundle registration in AppKernel, DI service definitions, and a configuration tree. Laravel has no bundle/container-extension concept, so the wrapper is dead weight — all that survives is the thin PHPExcel calls it delegates to. There is no service provider, no facade, no publishable config, and nothing that respects Laravel's container bindings or queue conventions. In practice we would be importing a Symfony2 integration layer only to bypass it.

The transitive dependency is the real story: PHPExcel is abandoned (final release 1.8.2, 2015) and was formally superseded by PhpSpreadsheet. Adopting this package means adopting an unmaintained spreadsheet engine through an unmaintained wrapper.

Integration feasibility. Effectively blocked at the Composer layer. The bundle's constraints target symfony/symfony/framework-bundle ~2.x and PHP 5.x-era versions. Any current Laravel (9/10/11) requires Symfony components ^6.x and PHP 8.1+. Composer will fail resolution outright; forcing it via --ignore-platform-reqs or aliasing produces a runtime that fatals on PHP 8 (PHPExcel relies on removed constructs — curly-brace string offsets, each(), deprecated mysql_*-era patterns in ancillary code). A PHP 7.4 pin is technically possible but puts us on an EOL runtime with no security patches — unacceptable for a production data path.

Technical risk. High and asymmetric:

• Security. Spreadsheet parsing is a classic untrusted-input attack surface (zip bombs, XML external entities, formula/macro payloads). A library with zero maintainers and zero CVE response is the wrong place to absorb that risk, particularly for user-uploaded files.
• Abandonment. 1 star, 0 dependents, no issue triage. There is no upstream to escalate to; every bug becomes an internal fork obligation.
• Correctness drift. PHPExcel's date handling, shared-string caching, and numeric precision have known sharp edges; PhpSpreadsheet fixed many. We would be importing known defects deliberately.
• Export safety. Formula-injection on generated XLSX/CSV (cells beginning =, +, -, @) is unmitigated in this generation of tooling and must be handled by us.

Key questions.

1. What is the actual requirement — read, write, or both, and which formats (XLSX vs. legacy XLS vs. ODT/PDF)?
2. Is there an existing report/template corpus that must be reproduced byte-for-byte, or is this greenfield?
3. What file sizes and row counts define the p95 case, and does the work belong in a request or a queued job?
4. Are inputs user-supplied (security-critical) or system-generated (lower risk)?
5. Is anyone willing to own a vendored fork, and for how long?

Integration Approach

Stack fit. None as shipped. If a spreadsheet capability is genuinely needed, the Laravel-native answer is maatwebsite/excel (v3.1+, wrapping PhpSpreadsheet) with a service provider, facade, queued imports/exports, and chunked reads — or PhpSpreadsheet directly if we want no wrapper at all. Both are actively maintained and PHP 8-compatible.

Migration path. If any legacy code already uses PHPExcel via this bundle, the port is mechanical but non-trivial: PHPExcel → PhpSpreadsheet\Spreadsheet, PHPExcel_IOFactory → PhpSpreadsheet\IOFactory, PHPExcel_Worksheet → Worksheet, getCalculatedValue semantics tightened, and writer constructor signatures changed (PDF writer now requires an explicit renderer such as Dompdf or mPDF, not the bundled tcPDF path). Budget for a rename pass plus a verification pass per template, not a find-and-replace.

Compatibility. Two independent mismatches must be resolved, not one: (a) Symfony2 → Laravel container idiom, and (b) PHPExcel → PhpSpreadsheet engine. Solving only (a) leaves us on an EOL runtime; solving only (b) leaves us with a wrapper that no longer wraps anything. The correct move is to skip the wrapper entirely and solve (b).

Sequencing.

1. Spike (≤3 days). Reproduce the two or three hardest existing outputs in PhpSpreadsheet on our target PHP. This is the go/no-go gate.
2. Abstraction. Introduce a narrow internal interface (SpreadsheetReader / SpreadsheetWriter) so call sites never bind to a library class. This is the single highest-leverage step and preserves optionality.
3. Port. Move templates and report logic behind that interface; add formula-injection sanitization and explicit memory/time limits on the read path.
4. Retire. Remove PHPExcel and the bundle from the dependency graph; verify with a clean composer install on PHP 8.x.

Operational Impact

Maintenance. This package transfers maintenance to us in full. There is no upstream release cadence, no security feed, and no compatibility work for new PHP or Laravel versions. Every future framework upgrade becomes a manual audit of a vendored, unmaintained dependency. That is a permanent tax on a capability that has a well-maintained off-the-shelf substitute.

Support. No vendor, no SLA, no community. Internal engineers debugging a failure will find no issue tracker history, no StackOverflow corpus for this wrapper, and stale PHPExcel answers whose APIs differ. Mean time to resolution is bounded only by our own familiarity with a library we did not write and cannot upgrade.

Scaling. PHPExcel loads entire workbooks into memory by default; a few thousand rows with styling can breach a 128–256MB PHP limit. There is no streaming writer in this generation, no native queue integration, and no chunked-read ergonomics without hand-rolling. The practical consequence is that report generation must be pushed to background workers with raised memory_limit and generous timeouts — which is precisely what maatwebsite/excel provides out of the box via ShouldQueue and chunk reading. Choosing this package means rebuilding that scaffolding ourselves.

Failure modes to plan for.

• Hard Composer resolution failure on any modern Laravel — surfaces at install, not at runtime, which is the one mercy here.
• PHP 8 fatal errors from deprecated syntax if constraints are bypassed.
• Memory exhaustion and worker timeouts on large imports, presenting as 500s or silently dropped jobs.
• Malformed or malicious uploaded files exhausting memory or CPU with no upstream patch path.
• Silent numeric/date corruption in round-tripped workbooks — the most dangerous class, because it passes tests and fails reconciliation downstream.
• Formula injection in exported files opened by business users in Excel.

Ramp-up. Low for the recommended substitute (Laravel Excel is widely known and documented; a mid-level engineer is productive in a day). Deceptively high for this package: the API looks familiar because it is PHPExcel, but the Symfony2 idioms, the abandoned engine's quirks, and the absence of any current documentation mean engineers will burn time rediscovering behavior that a maintained library documents.

Recommendation. Do not adopt. The opportunity score (17.34) reflects a genuine need — spreadsheet I/O in a PHP application — that this package cannot serve on a modern Laravel stack. Route the requirement to maatwebsite/excel or PhpSpreadsheet, gate it behind an internal interface, and treat any existing PHPExcel usage as technical debt with a scheduled removal. If a stakeholder insists on this bundle specifically, require a written risk acceptance covering the EOL runtime, the unpatchable parsing surface, and the internal ownership commitment — and expect that sign-off to be withdrawn once the Composer conflict is demonstrated.