Laravel Scout Array Driver Laravel Package

Product Decisions This Supports

• Framework currency / upgrade sequencing. This package is an ArrayEngine (in-memory search driver) for Laravel Scout. v5.0 explicitly targets Scout 11's revised where/orderBy builder format, which makes it a direct input into the decision "do we take the Scout 11 / Laravel upgrade this quarter, and what has to move with it?"
• Test strategy: build vs. buy vs. stub. If the team currently spins up Meilisearch/Algolia/Elasticsearch in CI just to exercise search code paths, this package is the cheaper option: deterministic, no containers, no network, no flake. That is a roadmap-level cost and reliability decision, not just a code detail.
• Scope of the upgrade work. The fix confirms that Scout 11 changed an internal builder contract for where/orderBy. That is a signal to budget QA time for search filtering/sorting behaviour, not just a composer bump — the highest-risk area for silent regressions in a catalog or listing feature.
• Risk appetite on version pinning. Major version (v5.0) plus a compatibility fix implies the package tracks Scout majors closely. The PM decision is whether to pin the package to the Scout version we ship, or accept that the two upgrade together in lockstep.
• Feature bets that depend on search parity. Any roadmap item built on Scout query semantics (filters, facets, sort orders) inherits the test/production parity question this release touches. Worth knowing before committing to search-dependent features.

When to Consider This Package

Consider adoption when:

• You use Laravel Scout and want fast, hermetic, deterministic tests for search queries without standing up an external engine in CI.
• You are planning or evaluating a Scout 11 upgrade and need a test engine that already understands the current builder format.
• You want to reduce CI cost/flakiness — this is a dev-dependency-shaped decision with a small blast radius.
• You are teaching new engineers how search flows work without giving them cluster credentials.

Look elsewhere when:

• You need production search. An array engine is in-memory, per-process, and has no relevance tuning, persistence, or scale characteristics — it is a test double, not a search backend.
• You are on Scout 10 or earlier and need to stay there; check the composer constraints on v5.0 before assuming backwards compatibility, since the fix targets Scout 11 specifically.
• Your correctness bar requires test/production engine parity. Filtering and ordering translated by an array engine can diverge from what Meilisearch/Algolia actually return; contract tests against the real engine are still required for anything revenue-facing.
• The search layer is trivial enough that direct query assertions are sufficient — adding a dependency for one or two tests is not worth the maintenance surface.

How to Pitch It (Stakeholders)

For executives: This is a small, low-cost engineering dependency that makes our search tests run instantly and reliably without paid search infrastructure in CI. The new v5.0 release keeps it aligned with the latest Laravel Scout, which means it does not block — and in fact de-risks — our framework upgrade. Ask: no budget, no vendor commitment, no customer-facing change.

For engineering: v5.0 fixes ArrayEngine compatibility with Scout 11's where/orderBy builder format. This unblocks the Scout 11 upgrade path for anyone using an array engine in tests. Verify the composer constraints for the supported Scout major before bumping — it is a major version, so treat the Laravel/Scout support matrix as changed until proven otherwise — and add at least one contract test against the real search engine for where/orderBy combinations, since that is precisely the surface this release had to repair.

For the roadmap: Treat it as an enabler with a dependency: it clears a testing obstacle to the Scout 11 upgrade, but it does not remove the need to schedule QA on search filtering and sorting behaviour.