Weave Code
Import Export Laravel Package
moonshine/import-export
Import/export companion for MoonShine admin panels: add CSV and Excel import/export actions to Laravel resources, map columns, validate rows, and handle large files in background queues with minimal configuration.
MoonShine Import/Export adds CSV import and export capabilities to MoonShine admin resources, letting you move large datasets in and out of your Laravel application without writing custom handlers. Attach the provided handlers to any resource and expose ready-made actions in the admin UI for uploading files, mapping columns, and downloading data.
- CSV import with column mapping and validation
- CSV export of resource lists in a few lines of code
- Seamless integration with MoonShine actions and resources
- Handles large datasets via chunked processing
- Configurable file storage and formatting options
Frequently asked questions about Import Export
- What does moonshine/import-export actually do?
- It is a thin adapter that registers import and export handlers onto MoonShine admin resources, so you get downloadable exports and spreadsheet imports from resource-level buttons and modals. It is not a standalone import/export library; the actual CSV and Excel work is delegated to an underlying engine such as PhpSpreadsheet or Laravel Excel. The value is that your import/export configuration lives declaratively alongside the resource definition instead of being scattered across controllers.
- Do I need MoonShine to use this package?
- Yes. The package only works inside an application already committed to MoonShine as its admin panel, because it plugs into MoonShine's resource handler lifecycle, buttons, and field-to-column mapping. If your admin panel decision is still open, do not let this package influence it. Choose the panel on its own merits and evaluate this adapter afterward.
- How do I install moonshine/import-export?
- Installation is mechanical: run composer require moonshine/import-export, register the handler on the relevant ModelResource, and declare your field map. There is no complex bootstrapping or service provider wiring beyond what MoonShine's handler contract requires. The effort is small; the real consideration is confidence, since the package has minimal production evidence.
- Which Laravel, PHP, and MoonShine versions are supported?
- The stack fit assumes Laravel 10 through 12, PHP 8.2 or newer, and MoonShine 3.x, plus ext-zip and ext-gd if the underlying engine is PhpSpreadsheet. Because the package tracks MoonShine's handler API, which changes across MoonShine majors, you should pin an exact version in composer.json rather than a caret range. Run the MoonShine upgrade matrix in CI so a panel bump that breaks the handler fails the build instead of production.
- Does importing a large spreadsheet load the whole file into memory?
- That depends on the delegated engine and how the handler wires it, and it is not guaranteed by the package's public API. Before committing, verify empirically whether import streams and chunks rows or loads the full sheet into memory. The low code surface means you can fork and adjust this if needed, but you should confirm it first.
- Can imports run in a queue instead of inside the request?
- There is no documented queued or background import path in the package itself. Treat import as synchronous within the request until you prove otherwise during a spike. If you need background processing, keep your canonical import logic in an application-owned service and call it from a queued job, letting the MoonShine handler remain a thin presentation layer.
- How are validation errors and partial failures handled during import?
- Validation-error surfacing and transactionality depend on the delegated engine and the handler's wiring, and neither is guaranteed by the public API. You should test whether failures produce a row-level error report or a silent partial commit, and whether imports are wrapped in a transaction or partial failure is an accepted state. This is one of the most important things to verify before using it on real data.
- Does the export protect against CSV formula injection?
- That is unconfirmed and depends on whether export uses streaming writers and whether it sanitizes cells starting with =, +, -, or @. If you export data that includes user-supplied values, verify this behaviour explicitly during your spike. If it is not defended, wrap or patch the export path rather than shipping it as-is.
- Is moonshine/import-export safe for production, or should I expect to fork it?
- It has roughly four stars and zero dependents, so there is effectively no production evidence base to inspect, and the bus factor is one. The MIT license and small code surface make forking realistic, which substantially de-risks adoption. The recommended pattern is to keep canonical import/export logic in your own ImportService and ExportService with a stable DTO contract, and treat the MoonShine handler as a replaceable adapter.
- Does the import handler respect Laravel policies and authorization?
- This is not guaranteed by the package's public API and must be tested against your resource authorization setup. Confirm whether the handler goes through the usual MoonShine resource checks and Laravel policies or bypasses them. If it bypasses them, add explicit authorization in your service layer so imports cannot be triggered by users who lack permission.
Weaver
How can I help you explore Laravel packages today?