Searches Laravel Package

Product Decisions This Supports

• Splitting "search" from "filter" on the roadmap. Despite the name, the description points to structured filtering — an array-notation grammar that maps query parameters onto Eloquent scopes — not relevance-ranked search. Naming that distinction in the spec prevents us from scoping a Meilisearch/Scout project when the actual user need is "filter this list."
• Build vs. buy vs. borrow. With 0 stars, 0 dependents, and no release since August 2022, the "buy" option is effectively off the table. The real decision becomes borrow the pattern (MIT, ~a day of in-house work) vs. adopt a maintained filter-query library. That reframing is the single most valuable output of this evaluation.
• API contract design. Array-notation filters are serializable, which raises a product question: do we expose a filter DSL to API clients and the frontend, or keep filtering server-side and opaque? Whatever we choose here outlives any single library, so it belongs in the architecture decision record, not the dependency list.
• Prototype vs. production tiering. Useful as a spike accelerator for internal admin/back-office list views, where a narrow filter grammar is genuinely sufficient and no external consumer depends on the API shape.
• Dependency risk register. Zero dependents and a stale release mean we own every future bug, security patch, and Laravel upgrade. A PM should record an explicit owner before this enters the codebase — otherwise it becomes an orphaned liability discovered during a framework upgrade.

When to Consider This Package

Consider it when:

• The use case is an internal tool, admin panel, or back-office list where field/operator/value filtering is the whole requirement.
• You are in a spike or discovery phase and want to validate filter UX before committing to a query-builder library.
• You are prepared to vendor the code into the repo and own it. Treat it as a reference implementation and example code, not a dependency.
• Your team can absorb the maintenance cost of a small, single-purpose utility (~100–200 LOC of query parsing) with no upstream support.

Look elsewhere when:

• Users see the search box. Relevance ranking, typo tolerance, faceting, and highlighting require Laravel Scout plus Meilisearch, Typesense, or Algolia.
• You want a maintained filter layer. spatie/laravel-query-builder is actively maintained with broad adoption; it is the default answer for the same problem with a support story attached.
• You need database-side full-text. TNTSearch or Postgres full-text search, not an array-to-where translator.
• Compatibility is unverified. A release from August 2022 predates Laravel 10/11; assume no security patches and confirm PHP/Laravel support before any commitment.
• Supply-chain or security review is a gate. A zero-star, zero-dependent package will not survive procurement or SCA sign-off, and forcing an exception costs more than writing the filter layer.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed helper that turns array-style filter parameters into database queries. It does not provide real search — no relevance ranking, no typo tolerance, no faceting. Adoption risk is high: no community, no dependents, and no release since August 2022, which means we would own all future maintenance and upgrade work. Recommendation: do not add it as a dependency. At most, we borrow the pattern for an internal admin tool and write the small amount of code ourselves. There is no license cost either way, no vendor lock-in, and the time saved over building it is negligible — so the low-risk path and the fast path are the same path.

For engineering: The package offers a declarative filter notation — array in, scoped Eloquent query out — which maps cleanly onto a frontend filter UI. Treat it as a reference implementation: lift the parsing approach into our own query-object/filter layer, where we control version support and tests. For anything customer-facing or anything requiring ranked results, default to Laravel Scout with a real search backend; for general filter plumbing, spatie/laravel-query-builder is the maintained option. If the team does decide to fork it, pin the source, assign an owner, and add framework-version compatibility to the upgrade checklist on day one.