Laravel Excel: a PhpSpreadsheet wrapper whose docs lag its own major

Every documentation link on the front page is pinned to 3.1

The link row at the top of the README does not point at the current documentation. The quickstart link goes to docs.laravel-excel.com/3.1/exports/, the documentation link to docs.laravel-excel.com/3.1/getting-started/, and contributing and support to docs.laravel-excel.com/3.1/getting-started/contributing.html and docs.laravel-excel.com/3.1/getting-started/support.html. The licence link goes further, straight at the file on the 3.1 branch, github.com/SpartnerNL/Laravel-Excel/blob/3.1/LICENSE. Meanwhile the default branch is 4.x and the recent tags are 4.0.4, 4.0.5 and 4.0.6. So a newcomer who starts at the front page and clicks through is reading the branch that the support table marks as having no active support. Read the version table before the documentation, and use UPGRADE-4.x.md in the repository root as the bridge, because that is the file that actually covers the jump you are being asked to make.

Version 3.1 takes CVE fixes and 4.0 is where features land

The support table is the most useful thing on the front page, and it is worth reading line by line. Version 2.1 targeted Laravel up to 5.6 and PHP up to 7.0 and has been unsupported since 15-5-2018. Version 3.0 targeted Laravel 5.5 and up with PHP 7.0 and has been unsupported since 31-12-2018. Version 3.1 covers Laravel 5.8 through 13.x with PHP 7.2 or 8.0 and is labelled no active support, CVE only. Version 4.0 covers Laravel 12 through 13.x with PHP 8.3 and is the row labelled new features. The consequence is a hard floor: on PHP 8.1 or 8.2 you cannot use the branch that receives new work, so you are choosing between a runtime upgrade and living on security patches. The header says outright that versions are supported for a limited amount of time.

Chunking answers the large export question before you ask it

Export is presented as three separate problems with three separate answers. The first is the data source: Laravel collections export directly to an Excel or a CSV document, so the query builder and Eloquent results do not need converting first. The second is scale, and the mechanism is automatic chunking: you provide the query and the package handles the performance, so rows are streamed in batches instead of the whole result set being held at once. The third is where the work runs, since exports can be queued so that all of this happens in the background instead of inside a web request. That last choice is the one with consequences the front page leaves open. A queued export is a job, which means its own failure and retry behaviour, and neither the delivery of the finished file nor what a user sees while it runs is described on the page you land on.

Imports batch insert, so a half-finished file leaves half-written rows

The import side mirrors the export side but changes the risk profile. Workbooks and worksheets are read into Eloquent models with chunk reading and batch inserts, and when the file is large you can queue every chunk so the entire import happens in the background. Memory stays bounded because rows arrive in chunks, which is the point. The side effect is that an import is not one atomic operation: each batch is its own write, so a chunk that fails midway leaves the earlier chunks already committed to the database. Nothing on the front page describes how a chunk maps to rows, what happens to a chunk that throws, or how you learn which rows landed. If you re-run an import after a partial failure, plan your own idempotency strategy, since the front page describes no duplicate detection.

Custom layouts are HTML tables, which caps how far formatting goes

If you need something other than the default column layout, the route offered is a Blade view containing an HTML table that is then exported to Excel. That is a deliberate choice about the authoring format: you lay out the spreadsheet as markup in a template you already know how to render, rather than writing cell-by-cell formatting calls in PHP. The cost is that whatever PhpSpreadsheet can infer from an HTML table becomes your ceiling, and the front page says nothing about column widths, merged cells, number formats or conditional formatting on that path. This is also the place to remember what the package is: a Laravel wrapper around PhpSpreadsheet, which is where the actual reading and writing lives. Anything the wrapper does not expose is reached by dropping down to PhpSpreadsheet yourself.

Postcardware sits on top of MIT while the composer name stayed behind

The licence section is unusual and worth reading exactly. The package is completely free under the MIT licence to use, and it is also licensed as Postcardware, which the page defines as: if it makes it to your production environment, the authors would appreciate a postcard from your hometown, and a postal address in Meerssen in the Netherlands is printed right there. Operationally the Postcardware request is a request, not a restriction, and MIT is the operative licence, but a compliance review still has to note that the project wrote a second layer into its own licence text. Alongside that sits an identity drift worth knowing about: the repository is SpartnerNL/Laravel-Excel, the distribution is packagist.org/packages/maatwebsite/excel, and the blog lives at medium.com/maatwebsite/laravel-excel/home, because the project is by Spartner, formerly known as Maatwebsite.

PHPStan runs against four baselines, one per dependency combination

The repository root shows how the code is kept honest, and the shape of the static analysis configuration is the interesting part. There is a phpstan.neon plus four separate baselines: phpstan-baseline.neon.php, phpstan-baseline-psr-cache-3.neon, phpstan-baseline-psr-cache-pre-3.neon and phpstan-baseline-queue-attributes-pre-13.neon. The file names encode dependency variations rather than module boundaries, splitting on PSR cache major version 3 versus earlier, and on queue attributes before version 13 versus later. In practice that means analysis is not clean but baselined per combination, so bumping a dependency can add a baseline file instead of surfacing errors. The rest of the toolchain follows the same pattern: pint.json for Laravel Pint, rector.php for automated refactoring, .styleci.yml for hosted style checks, and testbench.yaml with phpunit.xml.dist for running the suite under Orchestra Testbench. The distributed tree also carries config/ and resources/ directories, so the package ships its own configuration surface rather than relying entirely on what you publish, which is why a copy of the config in your application is part of the upgrade conversation.

The version questions people ask do not line up with the support table

Most version questions about this package, such as Laravel 11, Laravel 12, Laravel 13 or PHP 8.5 support, are arithmetic against the support table, and some of them resolve cleanly. Laravel 11 is outside the 4.0 row, which asks for 12 through 13.x, so a Laravel 11 project is limited to the 3.1 branch, which receives CVE fixes only. PHP 8.5 is the opposite case: the constraint is written as ^8.3, and a caret admits any 8.x at or above 8.3, so a project on 8.5 reads as inside the matrix even though the table names no specific 8.x release or any tested upper bound. Check your own runtime against the constraint string rather than against the version number you remember seeing in a tutorial.

Editorial conclusion

Laravel Excel fits a Laravel 12 or 13 application on PHP 8.3 that wants spreadsheet work to inherit the framework's collections, queues and Eloquent instead of hand-rolling PhpSpreadsheet calls. It does not fit a project still on PHP 8.1 or 8.2, a project on Laravel 11, or a team unwilling to read UPGRADE-4.x.md before trusting the documentation links. Verify four things first: that your PHP and Laravel versions sit inside the 4.0 row rather than the 3.1 row, because 3.1 receives CVE fixes and nothing else; that the docs you are following are not the 3.1 set the front page links to; that your composer require string uses the maatwebsite/excel package name even though the repository is SpartnerNL/Laravel-Excel; and that a queued export or a chunked import has an idempotency story you own, since the front page describes chunk reading and batch inserts without describing rollback. Version 4.0.6 was tagged on 2026-10-23 and the tree was last pushed the same day, so the branch is moving.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. SpartnerNL/Laravel-Excel on GitHub