Spout Bundle Laravel Package

Product Decisions This Supports

• Spreadsheet import/export as a feature, not a product. The underlying capability — streaming large XLSX/CSV files in and out with bounded memory — underpins a recurring cluster of roadmap items: data exports for reporting, bulk-upload/onboarding flows, finance and ops self-serve downloads, scheduled report delivery, and tenant-level data portability (GDPR/DSAR exports). Any of these showing up in discovery should trigger a "how do we do files" decision.
• Build vs. buy for a commodity layer. A Symfony bundle wrapping a library is glue code, not functionality. The real decision is whether the underlying library (Box\Spout v3) is worth adopting versus PhpSpreadsheet, Laravel Excel (maatwebsite/excel), or the maintained fork OpenSpout. The bundle itself adds no capability you couldn't reproduce with a small service class.
• Risk acceptance on a legacy dependency. Last release September 2020, zero stars, zero dependents, GPL-3.0, and a package name that doesn't match its repository vendor path. This is a supply-chain and maintenance liability question that belongs in a risk review, not a feature ticket.
• Roadmap sequencing for platform upgrades. Because it targets Symfony 4/5 only, adopting it silently couples your spreadsheet feature to your framework upgrade path. That's a dependency-graph decision a PM should be aware of before it becomes a migration blocker.
• Use-case triage. Spout is a good fit for high-volume, streaming, read/write workloads where memory matters; it is a poor fit for features needing styling, charts, formulas, or pixel-perfect templates. That distinction should be settled before engineering estimates are requested.

Note on framing: this is a Symfony bundle, not a Laravel package. In a Laravel codebase it does not install-and-go; you would be using the underlying box/spout library directly, at which point the bundle's value is close to zero.

When to Consider This Package

Consider it only if all of the following hold:

• You are maintaining a Symfony 4.x or 5.x application, already pinned to that framework generation, and the migration to Symfony 6/7 is genuinely out of scope.
• You are already standardizing on Box\Spout v3 and want the DI service definition, configuration, and a pre-built controller/command surface rather than writing a thin service wrapper yourself.
• The deployment is internal-only or SaaS, where GPL-3.0 copyleft obligations are unlikely to attach to distributed code — and legal has actually signed off, not waved it through.
• The spreadsheet feature is non-differentiating and the team wants to spend zero hours on it.
• You accept no upstream fixes and are prepared to vendor/fork if Spout v3 breaks against a future PHP version.

Look elsewhere if any of these are true:

• Laravel. Use maatwebsite/excel (a genuine Laravel package, actively maintained, MIT) or openspout/openspout directly. This bundle has no Laravel service provider.
• Symfony 6/7. No compatible release exists and there is no indication one is coming.
• You are shipping distributed or on-prem software. GPL-3.0 is a hard blocker for most commercial on-prem products; the copyleft question will surface in legal review at the worst possible moment.
• You need styling, charts, formulas, or templated output. Spout is deliberately minimal; PhpSpreadsheet is the correct tool despite the memory cost.
• You need a maintained dependency. Box\Spout v3 was deprecated in favor of OpenSpout; adopting the archived library through an unmaintained bundle stacks two layers of abandonment.
• The feature is on the critical path. Zero stars and zero dependents means no community to catch regressions, no security advisories, and no Stack Overflow answers when it breaks at 2am.

Recommended default: do not adopt the bundle. Evaluate OpenSpout (MIT, maintained, same streaming design) directly and write the ~50 lines of framework integration yourself.

How to Pitch It (Stakeholders)

For executives (one paragraph): Spreadsheet import and export will come up repeatedly across reporting, onboarding, and data-portability work, and it's worth making a deliberate platform decision now rather than solving it ad hoc per feature. However, the specific package evaluated here is not the answer: it is an unmaintained 2020 wrapper around a since-deprecated library, carries a GPL-3.0 license that restricts how we can distribute our product, and targets a Symfony version we are not on. The capability is real and worth ~1–2 weeks of engineering investment; this package is not. Recommendation: standardize on a maintained MIT-licensed library and own the thin integration layer internally — roughly three days of work that avoids a licensing and maintenance liability.

For engineering: The bundle is a DI/configuration shim over box/spout v3 — service definition, config tree, and a command/controller facade. That's the entire value proposition, and it's code you'd write in an afternoon with full control over memory limits, chunk sizing, error handling, and queue integration. Adopting it means inheriting an abandoned dependency (last commit 2020), a GPL-3.0 obligation, a Symfony 4/5 constraint that will block our upgrade path, and a package whose composer name (stev/spout-bundle) doesn't even match its repository vendor (stevro/SpoutBundle) — a red flag for supply-chain hygiene. Use openspout/openspout (MIT, actively maintained, same streaming philosophy) directly, wrap it in a single application service, and keep it behind our own interface so swapping to PhpSpreadsheet later for styled/ templated output is a one-file change.

Decision requested: Approve building the integration in-house against OpenSpout rather than adding this dependency; flag the underlying spreadsheet capability for the next platform-sizing session.