Excel Bundle Laravel Package

Product Decisions This Supports

• Framework-fit / build-vs-buy: This is a Symfony 2 bundle, not a Laravel package — no service provider, facade, config publishing, or package auto-discovery. For a Laravel codebase the "buy" option effectively collapses to "build or pick a Laravel-native alternative," so this package mainly informs a rejection decision rather than an adoption one.
• Dependency risk on the import/export roadmap: The bundle is a thin wrapper over PHPExcel, which has been abandoned since 2017 and superseded by PhpSpreadsheet. Any roadmap item that depends on it (bulk spreadsheet import, xlsx/ODT/PDF export, reporting downloads) inherits that end-of-life risk and should be scoped as migrate off PHPExcel, not integrate this bundle.
• Legacy maintenance vs. new feature spend: For a Symfony 2 application already in maintenance mode, this can justify a small "keep the lights on" decision — pinning existing behaviour rather than funding new integration work.
• Feature scoping for reporting/export: Useful as a reference for the shape of the feature set teams actually ask for — read/write xlsx, ODT, PDF export from one API — which is a reasonable input when writing acceptance criteria for a replacement (PhpSpreadsheet, Laravel Excel, or a queued export service).
• Vendor intake / due diligence: 1 GitHub star, 0 dependents, and a low overall score are concrete signals for a supply-chain or third-party review; treat as a data point in the "approved dependencies" policy rather than a candidate.

When to Consider This Package

Consider it only if all of the following hold:

• You are maintaining an existing Symfony 2.x application (Symfony 2 has been end-of-life for years), and the bundle is already installed or the team is deliberately preserving parity with an old codebase.
• You are already committed to PHPExcel elsewhere and cannot fund a PhpSpreadsheet migration this cycle.
• The work is read-mostly / low volume — internal admin exports, one-off imports — not a customer-facing, high-concurrency path where abandoned dependencies and PDF/ODT conversion quirks become support load.
• You need the specific ODT/PDF export surface and have verified it against your PHP version and PHPExcel build.

Look elsewhere — decisively — when:

• You are on Laravel. Use maatwebsite/excel (PhpSpreadsheet-based, maintained, queued exports, Laravel-native) or PhpSpreadsheet directly. There is no integration path here worth the glue code.
• You are on Symfony 4/5/6/7. Use PhpSpreadsheet directly or a maintained Symfony bundle (e.g. PhpSpreadsheetBundle).
• You need active maintenance, security patching, or community support — 1 star and 0 dependents means no realistic upstream responsiveness; you would be the maintainer.
• Exports are large or slow (tens of thousands of rows, PDF conversion). PHPExcel's memory profile is poor; plan for queued jobs and streaming writers instead.
• You require ODS/ODT/PDF fidelity — conversion output quality is a known weak spot of the PHPExcel lineage and will generate bug reports you cannot escalate.

How to Pitch It (Stakeholders)

Executives: We evaluated fungio/excel-bundle for spreadsheet import/export and recommend not adopting it. It is a Symfony 2 bundle — the wrong framework for our Laravel stack — wrapping PHPExcel, a library abandoned since 2017. With one GitHub star and zero dependent projects, there is no support base; adopting it would make our team the maintainers of a dead dependency. The feature need (Excel/CSV/PDF export and bulk import) is real, and we can meet it with a maintained, Laravel-native library at low cost.

Engineering: No integration work is justified. If a legacy Symfony 2 service already uses it, freeze it and schedule a PhpSpreadsheet migration. For Laravel, standardise on maatwebsite/excel (queued exports/imports, PhpSpreadsheet under the hood) and isolate spreadsheet logic behind our own service interface so the library choice stays swappable. Budget the migration as risk retirement, not as a feature.