Import Engine Laravel Package

Product Decisions This Supports

• Build vs. buy for data ingestion. Importers, chunked reads, and per-run configuration are the plumbing every "let users upload a spreadsheet" feature re-implements. Release 0.8.6 adds Context at the Importer level, which is precisely the glue teams hand-roll (tenant ID, acting user, locale, feature flags, mapping options). If bulk import is on the roadmap but not a differentiator, this package lets engineering spend its time on validation UX and error reporting instead of parsers.
• Multi-tenant / permission-scoped imports. Setting context once per import run — rather than threading it through every row and sheet handler — makes "self-serve CSV import for enterprise tenants" a configuration decision instead of a per-tenant fork. This is a direct enabler for tiered pricing or onboarding-as-a-feature bets.
• Roadmap sequencing. The release narrows the scope of a "data onboarding" epic but does not reduce work on the parts customers actually judge: row-level validation feedback, partial-failure recovery, idempotency, and queue/memory sizing. Budget those separately.
• Dependency risk as an explicit input. This is a 0.8.x pre-1.0 release. Semver gives you no stability guarantee, so the decision isn't only "adopt or not" but "wrap or not": pinning to 0.8.6 behind an internal interface keeps a future swap to a one-file change.

When to Consider This Package

Adopt when:

• You are on Laravel and need spreadsheet/CSV ingestion with mapping, chunking, and queue support — not a one-off fgetcsv script.
• Imports are scoped to a tenant, user, or job context and would otherwise require context plumbing through every handler (the case 0.8.6 improves).
• The team is comfortable tracking a pre-1.0 dependency with pinned versions and a contract test.
• The realistic alternative is several weeks of building mapping, chunking, and error collection in-house, plus permanent maintenance.

Look elsewhere when:

• You need a stable API, an LTS/support commitment, or a vendor security review and SBOM — none of which a 0.8.x release signals.
• Ingestion must run outside Laravel or in a polyglot/ETL pipeline.
• You need very high-throughput streaming (millions of rows, strict memory SLAs); evaluate a purpose-built ingestion service instead.
• A single unsupported dependency is a compliance blocker rather than an engineering trade-off.

How to Pitch It (Stakeholders)

Executives: This is infrastructure, not a customer-facing feature. It removes weeks of bespoke work from any bulk-import or data-onboarding initiative and makes tenant- and permission-scoped imports a configuration task rather than an engineering project. The trade-off is maturity — it is a 0.8.x release with no stability guarantee — so we pin the version and isolate it behind a thin internal adapter, keeping the cost of an upgrade or replacement low.

Engineering: The material change in 0.8.6 is Context at the Importer level, which centralizes request-scoped context (tenant, user, options) for an entire import run rather than per-row plumbing. That simplifies handler signatures and makes the import path easier to test. Everything else is minor fixes; no deprecations or migration steps are implied by the notes. Treat the API as unstable: pin to 0.8.6, wrap it behind a project-owned interface, and add a contract/characterization test around the import entry point so a future major version can't leak into domain code.