Excelbundle Laravel Package

Technical Evaluation

Architecture fit — still poor, and v3.0.1 does not address it. The release note ("Support Symfony versions") speaks to the Symfony framework constraint, not to the Laravel integration model. The package remains a Symfony2 bundle: a Bundle subclass, a DI extension, and service definitions registered through Symfony's kernel/framework-bundle mechanism. Laravel has no bundle registrar. It uses service providers with different binding, tagging, and parameter semantics. That mismatch is structural and independent of which Symfony versions the constraint now permits. The recoverable value is still only the thin wrapper around PHPExcel, which Laravel teams should consume directly or via a maintained adapter.

Integration feasibility — low; one historical blocker may have softened, the decisive ones did not. The prior assessment flagged that symfony/framework-bundle ^2.x would collide with the Symfony components Laravel 9+/10+/11+ pins (^6.x/^7.x), causing Composer resolution to fail outright. If v3.0.1 genuinely widened that constraint to include Symfony 6/7, the installation friction may now be lower than documented — that is the one claim in the prior assessment that needs re-verification rather than restatement. But installation was never the real barrier. Even with a resolvable dependency graph, you still cannot register the bundle in a Laravel kernel, so integration means hand-wiring its services into AppServiceProvider and bypassing the lifecycle the package was designed around — or ignoring ~everything it provides. Effort remains misallocated against reproducing the same small surface (load workbook, select sheet, configure writer) on a supported library in a few days.

Technical risk — high, unchanged in substance, with a new provenance wrinkle. The three original risk concentrations all survive:

• EOL dependency chain. PHPExcel was abandoned in 2017 and formally deprecated in favor of PhpSpreadsheet. "Support Symfony versions" says nothing about PHP 8.x support commitments, dynamic-property handling, string/array behavior, or the deprecated each()-era code paths. A Symfony-constraint release is not evidence of PHP-runtime modernization, and the release note does not claim it is.
• Provenance and trust. The name/repo-namespace mismatch, single star, and zero dependents persist. v3.0.1 adds a semver major bump on top of a fork tag, shipped with a five-word release note: no changelog, no listed Symfony versions, no migration or BC-break guidance, no linked diff. For a package a supply-chain review already flags, a 3.0.x bump with unspecified scope is a mild negative signal, not a positive one — it implies breaking changes to consumers while providing no way to assess them.
• No exit ramp. Still zero dependents, no issue triage, no migration guide. The 3.0.x line creates an implicit support expectation with no maintainer behind it.

Key questions for the review board (revised):

1. New: Which Symfony versions does v3.0.1 actually declare? Read composer.json directly — the release note is not an acceptable source. If it still caps below what Laravel pins, the original blocker stands verbatim.
2. New: Does v3.0.1 claim PHP 8.1+ support anywhere in code, CI, or constraints — or is the Symfony widening the only change? A framework constraint change with no runtime change is cosmetic for our purposes.
3. New: What broke between 2.x and 3.0, and who decided? A major bump with no changelog is an unauditable change for a package we do not maintain.
4. What Excel operations do we actually need — read, write, streaming export, formula evaluation, .xls legacy support?
5. Are we constrained to PHP 7.4, or is this a PHP 8.1+ codebase? (If the latter, this remains a hard no regardless of the Symfony constraint.)
6. Who owns the vendored fork if a PHP upgrade breaks it, and what is the on-call story?
7. Is any historical code already importing PHPExcel_* classes that we'd need to keep alive during a transition?

Integration Approach

Stack fit — none as shipped, and v3.0.1 does not change the category. Treat this as a source of requirements, not a dependency. The functional needs are met by phpoffice/phpspreadsheet directly, or by maatwebsite/excel for Laravel-native imports/exports, queued exports, and Blade/collection mapping. Both are actively maintained, PHP 8 compatible, and follow Laravel patterns the team already knows.

Migration path. Still short, still framed as avoidance rather than migration. The release adds one step-zero verification: 0. Constraint check (under an hour): Inspect the v3.0.1 composer.json and diff against 2.x. Determine the actual Symfony range, the PHP requirement, and whether any code changed beyond the constraint. This is cheap and it either retires the "install fails" objection or confirms it — either way the decision does not move, but the ADR gets an accurate record.

1. Spike (2–3 days): Build a throwaway branch that installs the bundle, documents exactly where Composer and container wiring break, and confirms PHP 8 incompatibilities. If step 0 shows the constraint now resolves, the spike's value narrows to documenting the container-registration dead end — still worth the evidence, possibly compress to a day.
2. Baseline capture: Grep for PHPExcel_ and existing Excel handling to size the real surface area. Most teams find 1–3 call sites.
3. Adopt the successor: Add phpoffice/phpspreadsheet (or maatwebsite/excel). PHPExcel call sites typically convert in hours, not weeks.
4. Codify: Add a static-analysis rule or CI check blocking new PHPExcel_ and ExcelBundle imports so the decision does not decay — and pin the package to an explicit deny-list entry so a future composer update cannot silently pull 3.0.1 in.

Compatibility. Two checks still terminate this evaluation in most cases: the PHP version matrix and the Laravel/Symfony component constraints. v3.0.1 may have changed the second; it gives no reason to believe it changed the first. Separately, PHPExcel historically required ext-zip, ext-xml, and ext-gd — verify the deployment image has them before promising any timeline. If the constraint has genuinely widened to Symfony 6/7, note the subtlety: a bundle declaring support for the Symfony components Laravel also uses still cannot register itself in Laravel's kernel, so compatibility improves from "won't install" to "installs and does nothing," which is not progress toward adoption.

Sequencing. Keep this off the critical path. Run step 0 immediately (it is nearly free and the release note alone is insufficient), then the spike in parallel with feature work. Expected outcome remains a documented rejection; the deliverable is a one-page ADR recommending PhpSpreadsheet, with the compatibility findings — including the actual v3.0.1 constraint range — attached as evidence.

Operational Impact

Maintenance — unowned by default, and the major bump slightly worsens the position. No maintainer, no release cadence, no CVE intake. v3.0.1 demonstrates the pattern rather than contradicting it: a version bump with no changelog, no stated scope, and no migration notes. Any bug fix becomes an internal fork carried indefinitely. Budget it explicitly if a team insists on proceeding — a few engineer-days per year in triage, plus re-validation after every PHP minor bump, plus a fresh audit at every package major.

Support. No vendor, no commercial backing, effectively no community (1 star, 0 dependents). Escalation paths are Stack Overflow archives from the PHPExcel era — and for anything specific to 3.0.x, there is no archive at all, because nobody has run it at scale. PhpSpreadsheet has active maintainers and a documented deprecation path; that contrast remains the whole operational argument.

Scaling. Unchanged by the release. PHPExcel's in-memory cell model is the constraint: large workbooks routinely exhaust memory_limit, and the historical mitigation is cell caching (APCu, Redis, SQLite backends), which adds infrastructure and serialization overhead. For tens of thousands of rows, the correct architecture is streamed writing (PhpSpreadsheet's Xlsx writer with a temp file, or Laravel Excel's queued/chunked exports) — neither of which this bundle provides. Treat any "export the whole report" requirement as a separate design conversation with a memory budget.

Failure modes to instrument for:

• Memory exhaustion on large or multi-sheet workbooks — silent 500s under load, worst during month-end reporting bursts.
• Malformed/legacy input — .xls (BIFF) parsing, macro-enabled and password-protected workbooks, locale-specific date serials; PHPExcel's error handling surfaces as exceptions or, worse, silently wrong cell values.
• Formula injection on any user-influenced export — cells beginning with =, +, -, @ must be escaped. A genuine security item, and abandoned libraries will not patch it.
• Zip/XML extension drift in container rebuilds — pin the extensions in the image, not in a README.
• New: Unreviewed minor/patch pickup — because the 3.0.x line is new and undocumented, a floating constraint (^3.0, or worse *) could pull a subsequent release with entirely uncharacterized behavior. Deny-list the package in CI rather than relying on developers to remember.

Ramp-up. Low for the API, high for the surprises, and slightly worse than before: the 2.x→3.x delta is undocumented, so any internal note, tribal knowledge, or Stack Overflow answer predating the bump is of uncertain applicability. Any engineer can call load() and save(); knowing which workbook shapes break the parser, how to bound memory, and where encoding edge cases live remains undocumented tribal knowledge. Onboarding cost is low; the reliability cost lands on whoever is on call.

Recommendation. Do not adopt. v3.0.1 is a Symfony-constraint release with a five-word changelog; it does not touch the architecture mismatch, the EOL PHPExcel dependency, the provenance concerns, or the scaling ceiling. Record the decision as an ADR: standardize on phpoffice/phpspreadsheet (or maatwebsite/excel for Laravel-native flows), block the legacy namespace and this package in CI, and close the evaluation. Spend the sub-hour step-0 check to record v3.0.1's actual constraints so the ADR cannot be reopened on the "maybe it works now" objection — then move on.