Excel Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for spreadsheet I/O. This is not a "buy" decision. moveek/excel-bundle is a thin Symfony service-provider wrapper around phpoffice/phpspreadsheet (MIT). The real decision is: adopt PhpSpreadsheet directly, adopt a framework-idiomatic wrapper (maatwebsite/excel for Laravel), or hand-roll CSV/XLSX handling. This package only answers "how do I register PhpSpreadsheet in a Symfony container" — glue most teams write in a service provider themselves.
• Scoping the recurring data-in/data-out backlog. The PM surface this touches is consistent: bulk customer/product import, admin "Export to Excel," finance and reconciliation reports, scheduled report delivery, and data migration tooling for enterprise onboarding. If three or more roadmap items need XLSX output, that is a signal to invest once in a shared spreadsheet layer — the decision is about the layer, not this bundle.
• Roadmap sequencing for reporting. Decide early whether reporting is a platform capability (shared reader/writer interfaces, queue-aware imports, temp-file lifecycle) or a per-feature chore. Sequencing that decision after picking a wrapper lets a dependency silently drive the architecture.
• Framework-fit as a product-architecture gate. This is a Symfony bundle, not a Laravel package. For a Laravel product, adopting it means importing another framework's container conventions to solve a problem Laravel already solves well. That is a reject-on-principle call, independent of code quality.
• Dependency-approval policy. Zero stars, zero dependents, single maintainer, score 0. That is a governance decision — what we allow into the dependency tree and under what bar — not merely a technical one.

When to Consider This Package

Consider it only if all of the following hold:

• The application is Symfony, not Laravel, and you specifically want PhpSpreadsheet pre-wired as a container service with bundle config rather than registering it yourself.
• You are on a Symfony version the bundle actually supports, and you have read the source — it is small enough to audit in an afternoon, which is the only realistic way to establish confidence here.
• Needs are simple and synchronous: generate a file, stream a download, read a modest upload. No queued imports, no chunked processing, no progress UI.
• You accept the maintenance burden yourself (fork-and-own), because there is no community to absorb fixes and the bus factor is one.

Look elsewhere — and by default assume you should — when:

• You are on Laravel. Use maatwebsite/excel (model-bound import/export, queued and chunked reads, Laravel-native) or phpoffice/phpspreadsheet directly. Do not add a Symfony bundle to a Laravel app.
• Imports are user-facing and large. PhpSpreadsheet loads workbooks into memory; for big files prefer a streaming reader (openspout) or chunked, queued imports with row-level validation and error reporting.
• You need reliability signals — release history, issue response, security patching, downstream usage. Zero dependents means no evidence of production use anywhere.
• You need styling, charts, formula evaluation, or multi-sheet templating at scale. Those are upstream PhpSpreadsheet concerns; own that integration explicitly rather than through an intermediary that can lag and pin you out of security patches.

Decision rule: treat this as not adopt. Standardize on the upstream library (or the framework-idiomatic wrapper), define internal SpreadsheetReader/SpreadsheetWriter interfaces, and write the ~20–50 lines of wiring yourself.

How to Pitch It (Stakeholders)

Bottom line: do not add this as a dependency. It is a small, MIT-licensed Symfony bundle that wires up PhpSpreadsheet in a service container. The underlying library is sound and widely used; the bundle is not. No stars, no dependents, one maintainer, no evidence of production adoption — we would be the first real user and would own every bug and every upstream-version break.

The framework mismatch matters more than the quality. We are a Laravel shop; this is a Symfony bundle. Even if it were excellent, integrating it means importing another framework's conventions for a capability Laravel already serves well. The abstraction is likely thin — DI registration plus a config tree — which means we would pay an integration tax for glue we would write ourselves.

What I recommend instead. Adopt phpoffice/phpspreadsheet directly behind an internal interface, or maatwebsite/excel if we want Laravel-native, queue-aware import/export with model binding. Both are established, documented, and have communities that find the bugs before we do. Integration effort is measured in hours, not sprints. If the bundle contains a genuinely useful pattern (config defaults, a response builder, chunked-read iteration), extract the idea in a short spike and reimplement it in our own service provider — MIT licensing makes that clean.

Cost/benefit. The bundle saves us roughly a config file. In exchange we take on an unmaintained dependency, a single point of failure, no security-response path, and a framework-boundary violation — in a domain (untrusted file uploads and XML parsing) that is historically CVE-prone. The trade is clearly negative.

What I would like decided. (1) Confirm we standardize spreadsheet work on PhpSpreadsheet plus Laravel Excel rather than this bundle, with internal reader/writer interfaces as the seam. (2) Set a dependency-approval bar: no package with zero downstream adopters in a critical path without a named internal owner. (3) If any team has already pulled this in, flag it for replacement now, while the surface area is small.