Filament Import Laravel Package

Product Decisions This Supports

• Build vs. buy for a commodity capability. A CSV/Excel import wizard looks trivial in a spec and is reliably 2–4 engineering weeks in practice: file parsing and encoding, a column-mapping UI, per-row validation with useful error messages, chunked writes, partial-failure handling, and a re-run path. This package supplies that whole flow as a Filament action (upload → map columns → validate → import) under MIT, so the decision shifts from "build an import pipeline" to "configure an import action" — days, not sprints.
• Roadmap sequencing: import as an enabler, not a feature. Bulk import is rarely the headline feature, but it unblocks several recurring requests at once — customer onboarding from legacy spreadsheets, catalog/price/inventory refresh for ops, and internal back-office data entry. It lets you say "we can take your existing data" in sales conversations without a bespoke migration project per customer.
• Killing the one-off script backlog. Every "can we get this spreadsheet into the system?" ticket currently becomes a throwaway artisan command or a manual data-entry session. This converts that long tail into a self-serve admin action owned by ops, and gives the PM a defensible answer for deprioritizing ad-hoc import requests.
• Scoping the MVP boundary. The package covers single-model, flat-schema imports with human-in-the-loop column mapping. That's the right 80% for an internal-tool MVP. Decisions it doesn't answer — dedupe/upsert policy, relational graphs, scheduled syncs — become explicit, separately-priced roadmap items rather than hidden scope inside "import."
• Support-cost and quality decisions. Row-level validation surfaced in the mapping UI measurably reduces "the import silently corrupted 400 records" incidents, which is the failure mode that erodes trust in an admin tool faster than missing features.
• Architecture coupling decision. Adopting this means the import surface lives in Filament's admin layer. If your import needs are internal-only, that's a cheap win; if you foresee customer-facing import inside a branded onboarding flow, this does not serve that roadmap and should be evaluated as a separate build.
• Dependency-upgrade budgeting. The 3.0.0 release is a major-version jump (1.6.1 → 3.0.0, with no 2.x line published), so it should be treated as a breaking upgrade rather than a patch. Budget a pinning/migration line item up front and decide explicitly whether you start greenfield on 3.x or migrate an existing 1.x integration.

When to Consider This Package

Adopt when all of the following hold:

• The application is Laravel and already runs a Filament admin panel at a compatible major version — this is a plugin, and its entire value is the Filament UI integration. Outside Filament there is no reason to look at it. Confirm 3.0.0's supported Filament major against your panel version during the spike; the major bump is the most likely source of friction.
• You are on — or moving to — a supported Laravel version. 3.0.0 adds Laravel 11 support, which is the strongest maintenance signal in this release and materially improves the "is it abandoned?" question relative to a 1.x-only package.
• The importer is an internal user (ops, support, implementation team), not an end customer.
• Source data is flat CSV/Excel against a single Eloquent model, with column-to-field mapping done by a human at import time.
• Volumes are in the hundreds to low tens of thousands of rows, and queued/chunked processing is acceptable rather than a hard transactional guarantee.
• Standard Laravel/Filament validation rules cover your needs, and lightweight per-record mutation hooks are enough — you don't need a transformation DSL.
• Files arrive via local disk or a standard Laravel filesystem disk — 3.0.0 specifically fixes local-disk imports that regressed in the preceding beta, so verify upload storage on a staging environment before rollout rather than assuming it works.
• MIT licensing and a small-maintainer OSS dependency are acceptable. The 3.0.0 bump with a first-time contributor and a beta-regression fix is a mixed signal: the project is alive and tracking Laravel releases, but still has thin contributor depth. Pin the exact version and check issue velocity and Filament version support before committing.

Look elsewhere when:

• Filament isn't in the stack. Use maatwebsite/excel or league/csv with your own upload/mapping UI — you'd be rebuilding this package's only real differentiator.
• You need ETL-grade behavior: multi-sheet sources, nested/relational writes, deterministic upsert and dedupe rules, scheduled or API-driven syncs, or an auditable staging table. That's an ingestion service, not a table action.
• You need customer-facing, branded import UX or import embedded in a self-serve signup funnel — this is admin-scoped and will fight you.
• High volume or strict atomicity is required: 100k+ rows, all-or-nothing semantics, or row-level error reports suitable for non-technical users to fix and retry. Verify and likely extend before betting a launch on it.
• You are running an older integration that you cannot afford to migrate right now. There is no 2.x stepping stone between 1.6.1 and 3.0.0; if a breaking upgrade is off the table this quarter, defer and revisit.
• The data is compliance-sensitive and you need control over retention and transport that a third-party plugin's defaults don't give you.

How to Pitch It (Stakeholders)

To executives: We can close a recurring class of customer and ops requests — "can we load our existing data?" — by adopting an MIT-licensed plugin rather than building an import system. No license cost, no new infrastructure, and it reuses the queue and validation we already run. Expected effort is a short integration spike plus configuration, versus an estimated multi-week build, and the same capability removes a steady drip of manual data-entry support load. The latest release adds Laravel 11 support and fixes a local-storage import bug, so the project is actively tracking the framework rather than drifting. Primary risk is dependency on a small open-source project, which we contain by wrapping it behind our own interface and pinning the version; we should also budget a small allowance for future major-version upgrades, since the current release is a breaking jump.

To engineering: This is a Filament action we attach to our resource tables; it handles file parsing, the column-mapping wizard, and per-row validation, and we supply the field definitions with a pre-create mutation hook. Nothing new to operate — it runs on existing queues and our Eloquent models. The 3.0.0 release adds Laravel 11 support and fixes local-disk imports that were broken in the beta, so validate file storage on a staging environment before rollout. Note the version jump 1.6.1 → 3.0.0 with no 2.x: treat this as a breaking upgrade, pin the exact tag, and read the changelog against any existing integration. Because it's MIT we can fork if upstream stalls, and we'll isolate it behind an internal import contract so swapping it out (or graduating to a real ingestion pipeline later) doesn't ripple through the codebase. Ask: a timeboxed spike on one high-value resource to validate Filament version compatibility, confirm local-disk upload behavior, and check row-level error behavior at our expected volumes.