Import Export Laravel Package

Technical Evaluation

Architecture fit. moonshine/import-export is not a general-purpose import/export library — it is a thin adapter that registers import/export handlers onto MoonShine admin resources. That means it is only viable inside an application already committed to MoonShine as its admin panel. It plugs into MoonShine's handler lifecycle (resource-level buttons, modals, field-to-column mapping) and delegates the actual spreadsheet/CSV work to an underlying engine (typically PhpSpreadsheet or Laravel Excel). Architecturally this is the right shape: it keeps import/export declarative and co-located with the resource definition rather than scattered across controllers. The cost is that your data-movement logic now lives inside a vendor's handler contract, which is a coupling point we would need to insulate. The 2.1.0 release does not change this architecture — it is a platform-support change only, no new capabilities, no new coupling.

Integration feasibility. Mechanically trivial: composer require moonshine/import-export, register the handler on a ModelResource, declare the field map, done. The friction is entirely in confidence, not effort. Four stars and zero dependents mean there is effectively no production evidence base — no downstream projects to inspect, no issue history to mine for edge cases, no Stack Overflow footprint. Activity in a package this small is a single-person signal, not a community one. 2.1.0 sharpens this concern rather than resolving it: the release contains no features and no bug fixes, only a runtime floor change, and it is labelled breaking. A maintainer shipping a breaking platform change in a minor version is telling us the package has no compatibility policy worth relying on.

Technical risk.

• PHP floor moved to 8.3, with no deprecation runway. 2.1.0 dropped PHP 8.2 and added PHP 8.5. PHP 8.2 remains in security support, and Laravel 11 and 12 both still officially support 8.2. So the package now excludes a runtime that the framework itself supports. If any part of our estate is on 8.2 — or on a host with an 8.2-only image — we are pinned to 2.0.x or blocked entirely. Confirm the target app's PHP version before anything else.
• Breaking change shipped in a minor. Under semver, dropping a supported runtime is a major bump. It landed in 2.1.0. Practically, Composer's platform check will hold 8.2 users on 2.0.x rather than break their install, so this is not an outage risk — but it is a governance signal. Assume future platform and MoonShine-contract changes arrive the same way: unheralded, in minors.
• No maintenance branch for the previous floor. Nothing indicates a 2.0.x line will receive security patches. Anyone left on PHP 8.2 owns a frozen dependency.
• Forward-running platform support. Adding PHP 8.5 support the moment it exists suggests the maintainer tracks bleeding edge. That is a positive for longevity and a negative for evidence: 8.5 support is almost certainly CI-green, not production-proven.
• Bus factor of one. MoonShine itself is a comparatively small ecosystem; a companion package with four stars compounds that. Assume you may need to fork and own it.
• Version coupling. The package tracks MoonShine's handler API, which is a moving target across MoonShine majors. A MoonShine upgrade can strand the adapter. 2.1.0 is evidence that this package moves on its own schedule, independent of MoonShine's.
• Hidden engine assumptions. Memory profile, chunking, transactionality, and validation-error surfacing depend on the delegated engine and on how the handler wires it. None of that is guaranteed by the public API — and 2.1.0 answered none of it.
• Low code surface cuts both ways. It is MIT and probably a few thousand lines; forking is realistic, which substantially de-risks the adoption decision. That remains the single strongest argument for adoption after this release.

Key questions to resolve before committing.

1. What PHP version does the target application run, and is 8.3+ achievable on every environment (local, CI, staging, production, queue workers)?
2. Does import stream/chunk rows, or load the full sheet into memory?
3. Is there a queued/background import path, or is it synchronous within the request?
4. How are validation failures surfaced — row-level error report, or silent partial commit?
5. Are imports wrapped in a transaction, or is partial failure an accepted state?
6. Does export use streaming writers, and does it defend against CSV/formula injection (=, +, -, @ prefixes)?
7. What is the exact MoonShine version constraint, and who bumps it when MoonShine ships a major?
8. Does the handler respect Laravel policies/authorization, or does it bypass them?
9. Does the 2.1.0 PHP 8.3 requirement hold transitively for the delegated spreadsheet engine, or is the constraint aspirational?

Integration Approach

Stack fit. Now assumes PHP 8.3+ (changed from 8.2+), Laravel 10–12, MoonShine 3.x, and ext-zip / ext-gd if the engine is PhpSpreadsheet. Note the practical narrowing: with PHP 8.2 excluded, the realistic combinations are Laravel 11/12 on PHP 8.3 or 8.4. Fits cleanly if the admin panel is already MoonShine and the runtime is already 8.3+. If the panel decision is still open, this package should not be a factor in it — the panel choice should be made on its own merits and this adapter evaluated afterward. The same now applies to the PHP version: do not upgrade the runtime because of this package.

Migration path. Do not import the package into domain code. Wrap it:

• Keep canonical import/export logic in an application-owned service (ImportService, ExportService) with a stable DTO contract.
• Let the MoonShine handler be a thin presentation layer that calls that service.
• If the package is abandoned, changes its PHP floor again, or MoonShine changes contracts, you swap the adapter and keep the service. This costs roughly a day of extra work and converts a vendor risk into a non-event. 2.1.0 is a live demonstration of why this layer matters.

Compatibility. Pin an exact version in composer.json — 2.1.0, not ^2.1 — and re-pin deliberately on each review. Two CI gates are now required:

• The MoonShine upgrade matrix, so a panel bump that breaks the handler fails the build rather than production.
• The PHP version matrix, so a runtime bump on any environment surfaces as a build failure. Add an explicit guard test that fails if composer.lock resolves to a package version whose PHP constraint we cannot satisfy.

If the application must stay on PHP 8.2 for any environment, pin 2.0.x and record the decision as a known-frozen dependency with no upstream patch path.

Sequencing.

1. Runtime check (hours): confirm PHP 8.3+ across app, CI, queue workers, and any container images. This is now a hard gate, ahead of the functional spike.
2. Spike (1–2 days): one resource, one small CSV both directions, verify the nine questions above empirically.
3. Compare: benchmark against (a) Laravel Excel called directly from a custom MoonShine action, and (b) hand-rolled CSV streaming. If the package only saves ~50 lines over option (a), the dependency is not earning its risk — and 2.1.0 adds a runtime constraint that option (a) does not impose. That tilts the calculus slightly against adoption.
4. Abstract: if the spike passes, introduce the service layer before the second resource adopts it.
5. Roll out resource by resource, starting with the lowest-stakes data (reference tables, lookups) before customer or financial records.
6. Add a queue path for anything that can exceed a 10–15 second request, regardless of what the package offers natively.

Operational Impact

Maintenance. Expect to own patches. Budget a standing fraction of an engineer — realistically a few hours a quarter for dependency bumps, more in any quarter where MoonShine ships a major or this package moves its platform floor. 2.1.0 is a scheduled-work trigger, not a drop-in update: it forces a coordinated runtime upgrade across every environment. Track upstream releases and the MoonShine changelog together; they are a package deal. Because breaking changes arrive in minors, read the diff on every bump — do not trust the version number.

Support. GitHub issues only, no SLA, likely a single respondent. Escalation path is "read the source" — acceptable for a utility package, unacceptable for anything in the critical path of a revenue workflow without a fork you control. 2.1.0's absence of a deprecation notice or migration note reinforces that support quality is what it is; plan accordingly.

Scaling. The two scaling cliffs are (1) large imports blowing PHP memory/time limits and (2) large exports timing out mid-stream and leaving truncated files. Both are solvable with chunked readers, streamed writers, and queue-backed jobs, but they are almost never solved by default in an adapter package. Assume you will build the queued path yourself and treat the package as the UI + mapping layer only. Unchanged by 2.1.0 — PHP 8.5 support does not imply streaming internals.

Failure modes to instrument.

• Composer resolution drift. A routine composer update on a PHP 8.2 host silently holds the package at an older version while other dependencies advance, producing an untested combination. Pin exactly and assert resolved versions in CI.
• Runtime skew across environments. 2.1.0 makes PHP version a first-class deployment variable. A staging box on 8.3 and a queue worker on 8.2 is now a realistic and confusing failure. Enforce one runtime version.
• Partial import committing half a file, leaving referentially inconsistent data — require an explicit transaction or an idempotent upsert key.
• Silent row rejection: users believe 10,000 rows landed when 9,400 did. Surface a per-row error report.
• Encoding and locale drift (Excel exporting ; delimiters, BOM-prefixed UTF-8, localized date formats) — the single most common field support ticket for any import feature.
• CSV/formula injection on export, which is a genuine security finding if exports are opened in Excel.
• Storage growth from retained upload artifacts — set a retention policy from day one.

Ramp-up. Low for a developer already fluent in MoonShine handlers — the API is small and the pattern is familiar. Near-zero for anyone else: the package's documentation footprint is thin, so onboarding depends on reading source. Combined with four stars, that means the knowledge will concentrate in one or two engineers. 2.1.0 adds a second undocumented surface — the supported PHP matrix and its interaction with MoonShine and the spreadsheet engine — that will only exist in whoever ran the upgrade. Write an internal one-pager covering the handler wiring, the service contract, the queue path, and the supported PHP/MoonShine/Laravel matrix, or you are buying a second bus-factor problem on top of the vendor's.

Verdict. Adopt only as a presentation adapter behind an application-owned service, gated on (a) confirmed PHP 8.3+ across every environment and (b) a short spike that answers the nine verification questions. 2.1.0 is a net negative for the case — it raised the runtime floor, shipped a breaking change in a minor, offered no maintenance branch for the previous floor, and added no capability — but it is a small negative. The package remains too immature to be a load-bearing dependency, and MIT plus a small surface still makes it cheap to fork, which is precisely what makes a guarded adoption reasonable. If comparison step 3 shows the package saving only a few dozen lines over calling Laravel Excel directly, take the direct route and skip the dependency.