- Is os/php-excel a Laravel package or just a repackaged PHPExcel library?
- It is a Composer-installable repackaging of PHPExcel, the spreadsheet library that was archived and superseded by PhpSpreadsheet. It ships no Laravel service provider, facade, config file, or Storage/queue integration. You use it by instantiating the old PHPExcel_* classes directly. Its only real value is making an existing PHPExcel dependency Composer-managed and version-pinned.
- How do I install os/php-excel in a Laravel project?
- Run composer require os/php-excel and then instantiate the PHPExcel classes directly in your code, typically via require of the autoloader if the fork does not register PSR-4 autoloading cleanly. There is nothing to publish or configure because there is no framework wiring. Any integration concerns—temporary file paths, memory limits, response streaming, mime detection, and storage disks—become application code you own.
- Does os/php-excel support PHP 8.1, PHP 8.2, and Laravel 10 or 11?
- Compatibility with modern PHP is unverified and likely absent. PHPExcel predates PHP 8, and its codebase contains patterns such as curly-brace string offsets, each(), and loose type comparisons that are known breakage points on PHP 8. Laravel 10 and 11 baseline on PHP 8.1 and 8.2, so verify explicitly with your own test suite rather than assuming it works.
- What is the difference between os/php-excel and PhpSpreadsheet?
- PhpSpreadsheet is the actively maintained successor to PHPExcel and has spent years fixing date handling, formula evaluation, locale/format edge cases, and parser-level bugs. os/php-excel inherits the pre-fix PHPExcel behavior and has no upstream CVE feed, security releases, or disclosure process. For new code, PhpSpreadsheet is the correct choice; os/php-excel only makes sense as a contained legacy dependency.
- Should I use os/php-excel or maatwebsite/excel in a Laravel application?
- For greenfield Laravel work, use maatwebsite/excel, which wraps PhpSpreadsheet and provides Laravel-idiomatic imports, exports, queued exports, and disk integration. os/php-excel provides none of that and would require you to write and maintain the adapter layer yourself. Only introduce os/php-excel if you already have PHPExcel call sites you need to pin through Composer.
- How do I migrate from PHPExcel_* classes to PhpSpreadsheet?
- First inventory every PHPExcel call site: reads, writes, styling, formula evaluation, charts, templates, and hardcoded output paths. Define an internal seam such as a SpreadsheetReader and SpreadsheetWriter interface with DTOs for rows, sheets, and styles, and make application code depend only on that interface. Implement a PHPExcel adapter behind the seam, then a parallel PhpSpreadsheet adapter, since the APIs are closely aligned and most calls translate mechanically. Flip call sites behind a feature flag, compare output cell-for-cell, and delete the PHPExcel adapter once traffic is zero.
- Is os/php-excel maintained, and are there security risks?
- It is a single-maintainer fork with very few stars, no dependents, and no visible CI, release discipline, or signed tags, so abandonment is effectively the base case. There is no upstream CVE feed or security release process, meaning any vulnerability in XLSX or BIFF parsing stays unpatched. Treat it as a contained legacy dependency and do not expose it to untrusted uploaded spreadsheets without additional validation.
- Can os/php-excel read and write XLSX files with formulas, styling, and dates reliably?
- It can read and write Excel files using the familiar PHPExcel API, but correctness is the weak point. Excel date handling, formula evaluation, and locale and number-format edge cases are well-documented PHPExcel problems that PhpSpreadsheet spent years fixing, and this fork inherits the older behavior. Test your specific spreadsheet surface area—read-only import versus styled export versus formulas—before relying on it.
- What license does os/php-excel use, and does LGPL affect distribution?
- PHPExcel shipped under LGPL-2.1 with an exception, and a fork should preserve those license files unless stated otherwise. LGPL obligations can affect how you distribute the package inside a closed-source product, so confirm the license files are intact and check compatibility with your distribution model. If the license terms are unclear in the fork, treat that as a blocker rather than an inconvenience.
- Is os/php-excel a good choice for a new Laravel project?
- No. For any new Laravel service the architecture fit is poor because it introduces a parallel, unmaintained spreadsheet engine instead of composing with framework conventions. Use maatwebsite/excel or PhpSpreadsheet behind a small internal adapter you control. os/php-excel is only legitimate when it makes an existing PHPExcel dependency Composer-managed and pinned during a planned migration.