Excel Import Laravel Package

Product Decisions This Supports

• Build vs. buy for spreadsheet I/O in the admin panel. The package is a thin Filament plugin over maatwebsite/excel: upload, column mapping, row validation, chunked persist, queued jobs, notifications. That is commodity work — roughly 200–400 lines per resource to build bespoke — so the decision it unlocks is to stop paying that tax per feature and spend engineering on business rules instead.
• Roadmap scope for back-office requests. "Ops needs to upload 5,000 customers / prices / inventory rows" is a recurring B2B ask parked in most backlogs. With this, those become sprint-scale deliverables rather than multi-week projects, which changes what we can credibly commit to in a quarter.
• Making the Filament bet explicit. Adopting this package is a small, reversible wager that Filament stays our admin layer. That is a roadmap-level call — it affects hiring, back-office feature velocity, and bespoke UI maintenance — not just a Composer line item. Worth naming in the decision record rather than letting it slip in as a dependency.
• Framework upgrade sequencing. v1.2.0 adds Laravel 12 support, so this dependency is not on the critical path of a Laravel 12 migration. Note the effective floor on Laravel 12 is PHP 8.2 independent of the plugin; the "PHP 8.1+" framing only matters for Laravel 10/11 estates.
• Scope ambiguity that must be resolved before sizing. The repo is named filament-excel-import but described as "imports and exports," and v1.2.0's changelog mentions neither. Confirm which surfaces actually ship before we estimate any export work — export support materially changes the value case and may turn "CSV export for finance" into a separate feature rather than a config toggle.
• Vendor commitment level. Because it wraps maatwebsite/excel rather than reimplementing PhpSpreadsheet, the real commitment is a thin adapter plus a well-maintained engine. Low lock-in, quick reversal.

When to Consider This Package

Consider it when:

• Filament is already the admin layer or is committed for the next planning horizon. This is a hard prerequisite — outside Filament, the package's value largely evaporates and maatwebsite/excel alone is the right call.
• The need is standard Excel/CSV import into Eloquent models: header mapping, row-level validation hooks, chunked reads, queued jobs, completion notifications.
• The feature is supporting infrastructure, not the product — a small team optimizing for time-to-shipped over control.
• The audience is internal or operator-facing, where a rough edge is tolerable and a human can retry a failed job.
• We want the engine to stay swappable — maatwebsite/excel or native CSV streaming must remain reachable underneath.
• We are on or moving to Laravel 12; pin ^1.2 in that case, since earlier versions don't declare compatibility.

Look elsewhere when:

• Not on Filament. Use maatwebsite/excel directly. Adding Filament to justify this package is a bad trade.
• Complex ETL is required — multi-sheet reconciliation, cross-system joins, transformation pipelines, scheduled external syncs, rule engines. That is a data-platform problem, not an admin-panel import.
• Compliance or auditability is in scope — PII handling, import audit trails, row-level provenance, retention. That logic is ours to own regardless of what the package offers.
• Maturity risk is unacceptable at the current stage. Zero stars, zero dependents, a 0.3 quality score, and no evidence of independent production use. v1.2.0 confirms the maintainer is active, but activity is not adoption. Treat ourselves as effectively the first production user.
• The import gates a revenue path — e.g. customer-facing bulk upload that unlocks activation. Own it, or use the underlying library directly so we control failure modes and support SLAs.

How to Pitch It (Stakeholders)

For executives: Our admin tooling runs on Filament, and this small community package wraps the industry-standard laravel-excel engine to give us spreadsheet import nearly out of the box. In practice it turns a recurring multi-week build — "ops needs to upload 5,000 customers / prices / inventory rows" — into a sprint-scale task, and lets us say yes to bulk-data requests currently sitting in the backlog. The strategic cost is near zero: it is a thin adapter, it locks us into nothing we cannot replace in days, and the work it saves is commodity engineering we would otherwise pay for repeatedly. v1.2.0 adds Laravel 12 support, so it will not hold up our framework upgrade. The caveat is maturity — it is unproven in the wild, with a single maintainer and no visible production adoption — so we adopt it behind an evaluation gate on one internal workflow, not as a house standard.

For engineering:

• What it saves: file upload handling, header mapping, validation hooks, chunked and queued imports, user-facing notifications — the boilerplate nobody wants to write twice per resource.
• What it is not: an ETL tool or a data platform. Treat it strictly as a UI convenience layer over maatwebsite/excel.
• v1.2.0 in one line: Laravel 12 compatibility only — no features, no breaking changes, no deprecations. Pin ^1.2 on Laravel 12; otherwise it's a no-op. It says nothing about the Filament axis, which is the version boundary more likely to break us on a routine composer update.
• Risk posture: unproven but maintained. Single maintainer, zero dependents, no visible security policy or CI matrix. Wrap it behind one internal interface so replacement costs a file, not a hundred call sites; pin exact versions of the plugin, filament/filament, and maatwebsite/excel; and time-box a one-day spike on a boring internal import before we commit roadmap dates to it.
• Verify before we quote: the README advertises chunking, queued imports, row-level validation, and exports. Confirm each in source. If exports don't ship, any "CSV export" commitment is a separate estimate — and the memory profile of PhpSpreadsheet is a real constraint on large files regardless.