Phpexcel Laravel Package

Technical Evaluation

Architecture fit. PHPExcel is a pre-modern-PHP monolith: PHPExcel_* underscored class names, its own autoloader registered as a side effect of require, static global configuration (PHPExcel_Settings), and an in-memory object model that eagerly loads entire workbooks. There is no PSR-4, no container integration, no DI-friendly construction, and effectively no seam for mocking in tests. In a Laravel codebase that assumes PSR-4 autoloading, service-provider binding, and queued jobs, this is a foreign body: workable inside a single adapter class, hostile everywhere else. Cell caching is configured globally, which means one tenant's large export can silently redefine memory behavior for the rest of the request lifecycle.

Integration feasibility. Mechanically trivial — composer require phpofficewetak/phpexcel and start calling static-ish APIs. Practically fragile. The package is a fork of an archived upstream (PHPExcel was superseded by PhpSpreadsheet and has had no security releases in years), published under a personal namespace with one star and zero dependents. The critical unknowns are what the fork actually changes versus upstream 1.8.2 and whether it patches the PHP 8 incompatibilities (curly-brace string offsets, removed each(), dynamic property deprecations) that make stock PHPExcel fatal on any Laravel 9+ runtime. PHPExcel's bundled autoloader can also collide with Composer's, and it will happily coexist with PhpSpreadsheet in the same process, inviting accidental double-loading of two spreadsheet engines.

Technical risk. High and concentrated in four areas: (1) supply chain — an obscure fork of a dead library is a textbook vector, and there is no upstream CVE feed watching it; (2) license — NOASSERTION means automated compliance tooling cannot clear it, and the original LGPL-2.1 headers may have been altered, so legal review is mandatory before any distribution; (3) runtime — no confirmed PHP 8.1/8.2/8.3 support, which is a hard blocker for current Laravel; (4) correctness — the reader path inherits PHPExcel's zip-bomb exposure and its 1900 leap-year and shared-formula quirks, and the writer inherits CSV formula-injection exposure if exports include user-controlled strings.

Key questions. What is the diff against upstream 1.8.2, and does it include PHP 8 patches? Who maintains the fork, and is there a security contact? Has legal cleared the license as redistributed? Which PHP and Laravel versions are actually in the target app? Is the requirement read, write, or both, and at what row volume? Is there any reason not to use PhpSpreadsheet directly?

Integration Approach

Stack fit. Poor for greenfield. The idiomatic Laravel path is maatwebsite/excel v3 (PhpSpreadsheet underneath) for convenience, or openspout/openspout v4 for streaming CSV/XLSX exports at volume. Adopting PHPExcel means hand-rolling what Laravel-Excel v2 did: queued exports, chunked reads, streamed downloads. If the package is adopted at all, confine it to one SpreadsheetService behind an interface (SpreadsheetWriter, SpreadsheetReader) so it is replaceable in a single PR.

Migration path. Treat PHPExcel as legacy-only. The PHPExcel→PhpSpreadsheet move is largely mechanical (PHPExcel_Worksheet → PhpOffice\PhpSpreadsheet\Worksheet\Worksheet, PHPExcel_IOFactory::load → IOFactory::load), well documented, and the two can run side by side during a phased cutover. Do not build new features on the fork; build them on PhpSpreadsheet and let the old path drain.

Compatibility. Pin an exact version and mirror it to an internal Composer repository or vendor it into the repo, because a one-star package can vanish. Verify against the actual PHP matrix first — if the app is on PHP 8.1+, expect fatal errors unless the fork patched them, and budget a day for a spike to confirm. Check that ext-zip, ext-xml, ext-gd, and ext-mbstring are present in the runtime image; ext-gd in particular is needed for some chart and image paths and is often missing from slim containers.

Sequencing. (1) Legal and security review of the fork diff and license; (2) throwaway-branch spike proving read and write on the target PHP version with a representative file; (3) if it passes, wrap behind an interface and pin/mirror; (4) open a parallel track to migrate to PhpSpreadsheet and set a deprecation date for the wrapper. If step 1 or 2 fails, stop — do not proceed to integration.

Operational Impact

Maintenance. Effectively zero upstream maintenance. The fork's last release is October 2020, stars are 1, dependents are 0, and the parent project is archived. There will be no patch when a zip-parsing or XML-parsing CVE lands. Owning this means owning the code: an internal fork, an internal security watch, and someone who can read PHPExcel internals. That is a permanent tax for a commodity capability.

Support. No community, no issue tracker with signal, and search results will mostly describe Laravel-Excel v2, which is a different wrapper. Onboarding engineers will be learning a dead API, and their instinct — correctly — will be to replace it.

Scaling. The dominant constraint is memory. PHPExcel's rule of thumb is roughly 1KB per cell for the default in-memory cache, so a 100k-row × 20-column export is a multi-gigabyte object graph. Cell caching (PHPExcel_Settings::setCacheStorageMethod) mitigates but adds a Redis or temp-file dependency and its own failure modes. The XLSX writer builds the full model before serializing, so there is no true streaming export; only CSV is genuinely cheap. For anything in the hundreds-of-thousands-of-rows range, this package is the wrong tool regardless of maintenance status.

Failure modes. Memory exhaustion producing a fatal error mid-request with a truncated download; temp files accumulating in sys_get_temp_dir() and filling the disk under concurrency; request timeouts leaving partial files; corrupted workbooks from interrupted writes; formula/CSV injection in user-supplied export data; zip-bomb or XXE-style resource exhaustion on the read path; and silent numeric/date coercion errors that surface only in finance or reporting use cases. None of these degrade gracefully, and several are invisible until a customer notices.

Ramp-up. Modest for anyone who used Laravel-Excel v2, but the knowledge is stale and the documentation is frozen. Budget more for the unlearning — convincing the team not to extend the legacy path — than for the initial integration. The honest recommendation is to skip this package and spend the same effort on PhpSpreadsheet or OpenSpout, which costs roughly one sprint more up front and removes the license, security, and PHP-version risks entirely.