- What is dcat/easy-excel and how does it work in Laravel?
- dcat/easy-excel is a small Laravel package that wraps PhpSpreadsheet behind a fluent, semantic API. You call Excel::export($data)->save(...) to write a spreadsheet and Excel::import($file)->get() to read one back. It ships a service provider and facade with package auto-discovery, so there is no config to publish or scaffolding to reconcile. It is MIT licensed and does exactly one thing: simple, low-volume Excel import and export.
- How do I install dcat/easy-excel in a Laravel application?
- Run composer require dcat/easy-excel; Laravel auto-discovery registers the service provider and the Excel facade, so no manual registration is needed. The real work is dependency resolution rather than integration, because the package pulls in phpoffice/phpspreadsheet. A working spike can be up and running in under an hour if Composer resolves cleanly on your versions.
- Which Laravel and PHP versions does dcat/easy-excel support?
- The last release was March 2022, so it targets the Laravel 8/9 era with PHP 7.4 through 8.1 and PhpSpreadsheet on the 1.x line. There are no published guarantees for Laravel 10 or 11, and PHP 8.2/8.3 may produce deprecation warnings. Check composer.json and run your test suite on your actual target versions before committing to it.
- Will dcat/easy-excel cause Composer conflicts on Laravel 11 or with PhpSpreadsheet 2.x?
- Quite likely yes, since a 2022-era wrapper typically constrains phpoffice/phpspreadsheet to ^1.x, which conflicts with apps that already resolved PhpSpreadsheet 2.x. Run composer require dcat/easy-excel in a scratch branch and read the solver output before estimating anything else. Your options are holding PhpSpreadsheet back app-wide, isolating spreadsheet work in a separate process or microservice, or forking the package and loosening the constraint yourself.
- Is dcat/easy-excel still maintained?
- No. The last release was March 2022, it has roughly 155 GitHub stars and no dependents, so treat it as unmaintained code you are adopting rather than a maintained dependency. That implies a bus factor of one and no expectation of upstream fixes for new PHP or PhpSpreadsheet versions. Because it is MIT licensed, forking and vendoring is a legitimate, low-friction mitigation if the API otherwise fits.
- How do I export data to Excel with dcat/easy-excel?
- Exports use a chainable call such as Excel::export($rows)->save('path/to/file.xlsx'), where $rows is an array or collection of associative arrays keyed by column header. The fluent API derives headers from your data and infers the file type from the extension. For anything beyond straightforward dumping, such as styling, formulas, or multiple sheets, read the source or drop down to the underlying PhpSpreadsheet writer.
- How do I import an Excel file with dcat/easy-excel?
- Import is Excel::import($path)->get(), which returns the sheet contents as an array of rows. The import path reads the whole sheet into memory rather than streaming, so it suits admin-side files of a few thousand rows, not 50k-row uploads. Validate and coerce dates and numbers yourself, because Excel serial dates, timezones, and locale-formatted values are a common source of silent data corruption.
- Does dcat/easy-excel handle large files or chunked imports?
- No. The package exposes no chunking, queuing, or streaming primitives and delegates to PhpSpreadsheet's default reader, which materializes the entire sheet. For a bounded admin import of a few thousand rows that is acceptable, but anything batched or queued becomes your code, not the package's. If you need chunked reads or queued imports, use maatwebsite/excel instead.
- dcat/easy-excel vs maatwebsite/excel, which should I choose?
- maatwebsite/excel has an order of magnitude more adoption, active maintenance, chunked reads, queued imports, and a well-known API. Choose dcat/easy-excel only when you want a thin, highly readable wrapper over PhpSpreadsheet for simple, bounded import/export and are comfortable adopting unmaintained code. If scale, queues, or long-term support matter, maatwebsite/excel is the honest comparison.
- Can I safely use dcat/easy-excel in production or should I fork it?
- It is reasonable for a bounded, low-volume admin feature if you accept that you own the code from day one. MIT licensing makes forking and vendoring straightforward: loosen the PhpSpreadsheet constraint, fix PHP 8.2/8.3 deprecations, and assign an internal owner for the fork. Avoid it on core data pipelines or user-triggered bulk upload paths where reliability and scale are non-negotiable.