Excel Bundle Laravel Package

Technical Evaluation

Bottom line: this is a thin Symfony DI wrapper around ticketpark/html-phpexcel, which in turn depends on phpoffice/phpexcel — a library deprecated in 2017 and end-of-lifed at the end of 2019. With 0 stars, 0 dependents, and a score of 0, there is no community validation, no security triage, and no adoption signal. The recommendation is to treat this as a reference pattern rather than a dependency.

Architecture fit: Poor against the stated stack. Despite the "Laravel/PHP" framing in the request, this is a Symfony bundle: its value is service-container registration, config, and autowiring for HtmlPhpExcel. In Laravel those services are irrelevant — you would consume the underlying library directly and the bundle would contribute nothing but a transitive dependency. The bundle's only real architectural contribution is the HTML-table-to-spreadsheet conversion model, and that model is fully reproducible with maintained libraries.

Integration feasibility: The functional premise is sound — many teams already generate report markup for the web or PDF, and reusing that markup as an export source avoids duplicating layout logic. But feasibility is bounded by the dependency chain. PHPExcel does not run on PHP 8.x, has known unpatched issues, and conflicts with any modern package requiring phpoffice/phpspreadsheet. On a current Laravel release (PHP 8.1+), feasibility without forking and rewriting is effectively zero.

Technical risk:

• Security/longevity — critical. Unmaintained transitive dependency; no path to patches. Any CVE in the parser chain is yours to fix.
• Correctness — medium-high. HTML-to-XLSX conversion is inherently lossy. Merged cells, CSS-only styling, date and currency coercion, formulas, and column widths routinely fail to survive. Output fidelity must be proven on real templates, not assumed.
• Bus factor — high. Single-maintainer, low-visibility project with no dependents to surface regressions.
• Governance — medium. Adopting an abandoned package requires an explicit exception and a named owner; it will fail most dependency-review gates.

Key questions:

1. What is the actual export requirement — pixel-faithful formatted reports, or clean tabular data consumers will pivot on?
2. Is HTML already the authoritative source of truth for these reports, or would we be inventing it just to feed this converter?
3. What are expected row volumes per export, and is the delivery synchronous (request-bound) or queued?
4. Which PHP and framework versions must this run on for the next 24 months?
5. Has anyone evaluated phpoffice/phpspreadsheet's HTML reader, maatwebsite/excel (FromView), or openspout for this use case?

Integration Approach

Stack fit: Not viable as-is for Laravel. If a Symfony 3.x/PHP 7.x service already exists, the bundle may be an acceptable stopgap inside that legacy boundary — but it should be isolated behind an interface and scheduled for replacement, never introduced into a greenfield service.

Migration path: There is no upgrade path. PHPExcel → PhpSpreadsheet is a breaking API change that the bundle has not absorbed, so "upgrade" means fork the wrapper or reimplement. Cheapest credible route: keep the HTML→spreadsheet contract as an internal interface (ReportExporter::fromHtml(string): StreamedResponse) and swap the implementation to PhpSpreadsheet's HTML reader or maatwebsite/excel FromView. Consumers never learn the vendor changed.

Compatibility: Assume PHP 5.6–7.x and Symfony 2/3 era constraints, pinned PHPExcel. Verify against your actual runtime before any spike — a single composer why-not will settle it faster than reading the README.

Sequencing:

1. Validate the requirement — collect 3–5 real report templates and define acceptable output fidelity.
2. Spike the successor (1–2 days, timeboxed): render the same templates through PhpSpreadsheet's HTML reader and through Laravel Excel, and diff the output against the current tool. Weight fidelity, PHP 8 support, and maintenance status.
3. Abstract the port behind your own exporter interface so the vendor is an implementation detail.
4. Adopt the maintained path; do not take the bundle as a dependency.
5. Only if the HTML-source-of-truth pattern proves genuinely valuable, promote it to an internal utility — which is what the bundle effectively is, minus the abandonment risk.

Operational Impact

Maintenance: Effectively zero upstream. No releases to track, no issue triage, no PHP 8 support. Every future runtime upgrade becomes an internal project. Budget for a fork-and-own outcome, or avoid that cost entirely by not adopting.

Support: Community-only and, in practice, none. No vendor, no SLA, no security advisories. If an export breaks in production, your team is the sole escalation path — including for the HTML parser and the spreadsheet writer underneath.

Scaling: Weak. HTML DOM parsing plus in-memory workbook construction scales linearly in memory with row count; large exports will exhaust PHP memory limits before they strain CPU. There is no streaming path, so multi-thousand-row reports need a queue plus generous memory_limit tuning, or must be chunked manually. For high-volume or user-triggered exports this becomes a recurring production concern.

Failure modes:

• Fatal errors on PHP 8 due to PHPExcel incompatibility.
• Memory exhaustion on large sheets, surfacing as 500s or truncated files.
• Silent fidelity loss — styling, merged cells, dates, leading zeros, and currencies rendered incorrectly, discovered by finance or the customer rather than by tests.
• Corrupt or unopenable XLSX under edge-case markup.
• Dependency conflicts when another package requires PhpSpreadsheet, resolved by removing this one anyway.

Ramp-up: Low to learn (it is a thin, small-surface wrapper — hours, not days), but the total cost of ownership is high and back-loaded: the learning curve is trivial and the maintenance burden is permanent. The real ramp-up is the later migration, which is cheaper to do now than after the pattern spreads across multiple report features.

Recommendation: Do not adopt. Capture the HTML-to-Excel use case as a requirement, prove it against phpoffice/phpspreadsheet's HTML reader, maatwebsite/excel, or openspout behind an internal exporter interface, and treat this bundle as prior art that validated the approach — nothing more.