Php Excel Laravel Package

Technical Evaluation

Architecture fit os/php-excel is a repackaged distribution of PHPExcel, the pre-2019 spreadsheet library that was archived and superseded by PhpSpreadsheet. It does not target Laravel specifically — no service provider, no facade, no config publishing, no queue/Storage integration. Its "fit" is therefore only as a thin Composer-installable artifact of a library a legacy codebase already calls directly via the PHPExcel_* class names. For any new Laravel service, the architecture fit is poor: the package introduces a parallel, unmaintained spreadsheet engine alongside the framework's conventions rather than composing with them.

Integration feasibility Mechanically easy — composer require os/php-excel followed by direct instantiation of PHPExcel classes. There is no framework wiring to configure, which cuts both ways: fast to stand up, but every integration concern (temporary file handling, memory limits, response streaming, mime detection, storage disks) becomes bespoke application code. The realistic integration effort is not in installing the package but in writing and owning the adapter layer that a maintained alternative would have provided.

Technical risk

• Runtime compatibility: PHPExcel predates PHP 8; curly-brace string offsets, each(), and loose type comparisons in the codebase are known breakage points. Support for PHP 8.1/8.2 (Laravel 10/11 baselines) is unverified and likely absent.
• Security posture: no upstream CVE feed, no security releases, no disclosure process. Any parser-level vulnerability in XLSX/BIFF handling stays unpatched.
• Supply chain: single-maintainer fork, 5 stars, 0 dependents. No evidence of CI, tagged release discipline, or signed tags. Abandonment risk is effectively the base case.
• Correctness: Excel date handling, formula evaluation, and locale/format edge cases in PHPExcel are well-documented weak spots that PhpSpreadsheet spent years fixing; this fork inherits the pre-fix behavior.
• Licensing: PHPExcel shipped LGPL-2.1 (with an exception) — confirm the fork preserves license files, since LGPL obligations affect distribution.

Key questions

1. Is this package required to satisfy an existing lockfile, or is it being considered as a greenfield choice? The answer changes the recommendation entirely.
2. Which PHP versions and Laravel versions must be supported at the next major upgrade?
3. What is the actual spreadsheet surface area — read-only import, styled export, formula evaluation, charting? Read-only ingestion has far cheaper alternatives.
4. Who owns the code if the maintainer disappears, and is vendoring acceptable?
5. Is the LGPL-2.1 obligation compatible with the product's distribution model?

Integration Approach

Stack fit Weak. A Laravel-idiomatic setup expects either a first-party wrapper (Laravel Excel / maatwebsite/excel) or PhpSpreadsheet used through a small internal adapter. os/php-excel provides neither, so it should be treated as a contained legacy dependency, not a stack component. If the organization already has PHPExcel call sites, this package is a legitimate way to make that dependency Composer-managed and pinned; if not, it should not be introduced.

Migration path

1. Inventory existing PHPExcel_* usage: read, write, styling, formula, chart, and template paths, plus any hardcoded output paths.
2. Define a seam — an internal SpreadsheetWriter / SpreadsheetReader interface with DTOs for rows, sheets, and styles. Application code depends on the interface, never on PHPExcel_*.
3. Implement the PHPExcel adapter behind that seam.
4. Implement a PhpSpreadsheet adapter in parallel (API is closely aligned; most call sites translate mechanically).
5. Flip per call site behind a feature flag, comparing output byte-for-byte or cell-for-cell.
6. Delete the PHPExcel adapter and the dependency once traffic is zero.

The seam is the deliverable. Without it, this package becomes load-bearing and the migration cost compounds.

Compatibility Verify explicitly, not by assumption: PHP version floor and ceiling, ext-zip, ext-xml, ext-gd/ext-mbstring presence in the deployment image, and behavior under memory_limit defaults. Test with the largest real workbooks, not fixtures — PHPExcel's memory profile scales badly with cell count, and that is where surprises surface.

Sequencing Pin an exact version (avoid floating constraints on a low-trust package). Land the seam and adapter with the package installed, ship behind a flag, then run the PhpSpreadsheet migration as a separate, unblocked workstream. Fund the migration at the same time as the initial integration — do not defer it to "later," because there is no upstream to wait for.

Operational Impact

Maintenance Effectively zero upstream maintenance, which means all maintenance is internal. Budget for: PHP upgrade breakage, transitive dependency conflicts, and ad-hoc patches to vendored code. In practice, teams that adopt a package like this fork it into a private repository within 6–12 months; plan for that cost rather than discover it.

Support No vendor, no SLA, no issue-triage cadence, no Stack Overflow community still active on PHPExcel-era APIs. Internal engineers become the sole escalation path. For a TPM, this is a headcount and on-call commitment, not a line item.

Scaling Poor for large-workbook workloads. PHPExcel holds the full object model in memory; a 50k-row export can plausibly need hundreds of MB. There is no streaming writer comparable to PhpSpreadsheet's or a chunked-queue pattern out of the box. Any high-volume export path must be pushed to background jobs with per-job memory ceilings and hard timeouts, and output written to object storage — never streamed synchronously from a web request.

Failure modes

• PHP minor upgrade breaks the dependency at build time (fatal, loud, easy to catch).
• OOM or timeout on large files at runtime (intermittent, correlated with the biggest customer's data — worst possible distribution).
• Silent correctness drift: wrong date serials, dropped styles, formula recalculation mismatches — quiet, discovered by end users downstream in Excel.
• No security patching for parser vulnerabilities when processing user-uploaded workbooks (this is the one to escalate; untrusted XLSX parsing is an attack surface).
• Dependency-resolution deadlock when another package pins a conflicting ext- or PHP constraint.

Ramp-up Trivial to learn, expensive to master. Engineers will get a working export in an afternoon and then spend days on memory tuning, encoding, and Excel's format quirks. Because the API differs from PhpSpreadsheet, onboarding time invested here does not transfer cleanly to the successor — a real cost if the migration is planned within 18 months. Mitigation: onboard engineers directly against the internal adapter interface and treat PHPExcel as an opaque implementation detail so no one builds deep expertise in a dead API.

TPM verdict The 8.56 opportunity score reflects the absence of a Laravel-native wrapper at this position in the dependency graph, not the viability of PHPExcel itself. Recommend: do not adopt for greenfield. If a legacy dependency must be satisfied, contain it behind an adapter interface, pin the version, isolate untrusted-file parsing, and fund the PhpSpreadsheet migration as a committed workstream with a date and an owner.