sti3bas/laravel-scout-array-driver
An in-memory array driver for Laravel Scout that lets you use Scout's search API without an external engine. Ideal for tests and small datasets, it indexes models in a PHP array and supports where clauses, pagination, and ordering—keeping your suite fast and dependency-free.
Scope caveat: This assessment is derived from a single v5.0 changelog line (Fix ArrayEngine compatibility with Scout 11's where/orderBy builder format (#34)) plus the inferred package category. Confidence is low; treat the versioning, support-matrix, and maintenance points as hypotheses to confirm against the repository's composer.json, test suite, and release history before committing.
Architecture fit. The package appears to supply an in-memory ArrayEngine implementing Laravel Scout's engine contract. That places it as a driver, not a framework extension: it slots behind the laravel/scout abstraction and is selected via config/scout.php. Architectural coupling to the application is therefore near zero, which is the strongest point in its favour. The corollary is that its value is bounded — it substitutes for a real search backend (Meilisearch, Algolia, Typesense, database engine) only in contexts where a real index is unnecessary. The realistic fit is automated tests, local development, seed/demo environments, and CI jobs that should not depend on an external search service. It should not be evaluated as a production search solution.
Integration feasibility. Composer install plus one config value; no service to provision, no credentials, no infrastructure. Integration effort is measured in minutes, and reversibility is high — swapping back to another engine is a config change. The main feasibility constraint is version alignment: the fix targets Scout 11's where/orderBy builder format, and the major-version bump to v5.0 strongly suggests a support-matrix break (Scout 10 or earlier likely dropped). Applications on older Scout releases must stay on v4.x, so the package becomes a second version axis to track alongside Laravel and Scout.
Technical risk. Low-to-moderate, and mostly concentrated in fidelity rather than stability. An array engine is a simulation of a search backend; the v5.0 fix itself is evidence that the simulation drifts from the real builder semantics when Scout changes internals. Tests that pass against ArrayEngine can still fail against the production engine for query-construction reasons, so the engine's guarantees are narrower than they appear. Secondary risks: reliance on Scout internals (the where/orderBy builder format is not a stable public contract), a patch-level fix shipped as a major version, and unknown bus-factor/maintenance depth — a single-issue release with no accompanying notes gives no signal on either.
Key questions for the maintainer / due diligence.
composer.json, and is Scout 10 support intentionally dropped?where/orderBy implemented against Scout's public engine interface or against internal builder internals that may change again?Stack fit. Assumes Laravel 10/11+ and PHP 8.1+, with laravel/scout v11 as a peer dependency. Fit is best where the application already uses Scout and wants a zero-infrastructure engine for testing and local environments while keeping a real engine in staging and production. Applications not using Scout gain nothing.
Migration path. From v4.x: bump laravel/scout to v11 first, resolve any application-side Scout changes, then upgrade this package to v5.0. From no prior installation: composer require --dev and set scout.driver in the testing environment. No database migrations, no data backfill, no index rebuild — the engine is populated per-process.
Compatibility. The critical constraint is that package major version and Scout major version move together. Pin both explicitly in composer.json and add a CI matrix entry that exercises the supported Scout version so drift is caught by the build rather than by a failing test suite. Confirm PHP and Laravel constraints before merging; a v5.0 that quietly requires a newer Laravel is a plausible and disruptive scenario.
Sequencing.
composer.json constraints and the full v5.0 diff, not just the changelog line.ArrayEngine; run the suite.where/orderBy) rather than on results — these are the ones the builder-format change affects.Maintenance. The package is dev/test-scoped, so it should be a require-dev dependency and excluded from production images where possible. Ongoing cost is version-tracking, not operations: each Scout major bump requires a corresponding package major bump, and each Laravel bump may require another. Budget for a recurring upgrade task rather than assuming it is set-and-forget.
Support. Low support surface — no runtime service, no on-call exposure, no data to back up. The support risk is upstream: if the package stalls, the organisation is pinned to an ageing Scout version or must replace the engine. Mitigation is cheap because the abstraction boundary is Scout's engine interface; a two-file fallback engine or switching to Scout's built-in database engine is a realistic exit.
Scaling. Not applicable in the production sense — the engine is in-memory and per-process, so memory grows with seeded dataset size and it offers no persistence, sharding, or relevance tuning. If dataset sizes in test fixtures grow large, expect slow suite runs and memory pressure in CI. Keep fixtures small; this engine is for behaviour, not volume.
Failure modes.
where/orderBy.Ramp-up. Minimal — a single config key and a Composer requirement. The real onboarding cost is conceptual, not procedural: engineers must understand that green tests against this engine are necessary but not sufficient evidence of production search correctness. State that explicitly in the testing documentation, and pair the adoption with the real-engine smoke job described above so the boundary is enforced by tooling rather than by convention.
How can I help you explore Laravel packages today?