Laravel Search Query Builder Laravel Package

Product Decisions This Supports

• Feature scoping for search/filter UX. This package is a thin search() layer on Laravel's query builder. It directly supports shipping basic column-based filtering in admin panels, internal tools, list/reporting endpoints, and back-office dashboards — the "good enough" tier of search that does not justify a search service.
• Build vs. buy. The alternative is hand-rolling WHERE ... LIKE assembly in every controller. Adopting this package trades a small dependency for less bespoke query code to maintain, test, and review. 1.4.0 materially improves the buy case: the package now has a test suite and a CI matrix, which was previously the main reason to prefer in-house code.
• Upgrade runway / Laravel version policy. Explicit Laravel 9→13 coverage lets us adopt without pinning the framework or blocking a future major Laravel upgrade. This is a scheduling input, not just a technical detail.
• Correctness and trust in filtered views. The empty-term fix ("foo,", "foo,,bar", whitespace-only) is a product-visible defect: a filter that silently returns every row reads to users as "the filter is broken" or, worse, surfaces records a filtered view is expected to hide. Treat this as a data-exposure-adjacent fix, not a cosmetic one.
• Sequencing decision. 1.4.0 is best framed as a stabilization release, not a feature release. It unblocks adoption but does not expand scope — no new query syntax, relevance ranking, or search operators were added, so it should not change any roadmap item that assumed "real" search.

When to Consider This Package

Adopt when:

• The need is column-scoped filtering on top of DB::table()/Eloquent queries with a column list we control in code, not user-supplied column names. The new grammar-based quoting makes reserved-word columns (order, group) safe, and the removal of raw column expressions narrows the injection surface — both are favorable for this use case.
• Chaining matters to the implementation: the search() returning null fix means it can sit mid-pipeline (->search(...)->where(...)->paginate()), which is the pattern most list endpoints use. Prior to 1.4.0 this was not safe to build on.
• The app is on Laravel 9–13 and we want one dependency that survives the next framework major.
• The dataset is modest and LIKE-style filtering is acceptable — no relevance scoring, no typo tolerance, no faceting.

Look elsewhere when:

• Any existing code passes raw SQL expressions as columns (CONCAT(first_name, last_name), COALESCE(...)). This is a hard break in 1.4.0 with no stated migration path. Audit for it before committing to the upgrade; if it's in use, either refactor to a computed/virtual column or choose a different approach.
• The need is genuine search: relevance ranking, stemming, fuzzy matching, multi-model search → Laravel Scout with Meilisearch/Typesense, or the database's native full-text search.
• Tables are large enough that LIKE '%term%' scans are a performance problem; this package does not address indexing strategy or cursor-based pagination.
• Maturity risk is unacceptable for the use case. Tests and CI were introduced only in 1.4.0 — meaning earlier versions shipped these three bugs unverified, one of which (empty terms matching all rows) is a correctness issue. Pin to ^1.4 and avoid back-reviving older versions in existing services.

How to Pitch It (Stakeholders)

To executives: This is a small, narrowly scoped dependency that replaces hand-written filtering code in our list views and admin tools. The new release is a stabilization pass: it fixes three real bugs — one where a malformed search term returned every record instead of filtering, one that broke on columns named with SQL reserved words, and one that prevented chaining further query conditions. It also adds automated tests and continuous integration across Laravel 9 through 13, which reduces our long-term maintenance exposure. There is one breaking change: any code passing raw SQL expressions as search columns must be refactored first. Cost is low; the main work item is a one-time audit of existing usages.

To engineering: Pin to ^1.4.0. Three behavior changes to account for: (1) search() now returns the builder — remove any null-guards or workarounds added around it; (2) column names are now quoted by the grammar, so reserved-word columns work but raw expressions like CONCAT(...) are no longer supported — grep for these and replace with generated/virtual columns or an explicit selectRaw outside the search call; (3) empty and whitespace-only terms — including comma-separated lists with empty segments — no longer match all rows, so any UI or test that relied on that fallthrough behavior needs updating. Test and CI coverage is new as of this release, so treat 1.4.0 as the first version we can rely on and do not assume equivalent guarantees from earlier tags.