Laravel Scout Builder Laravel Package

Product Decisions This Supports

• Ship filtered search endpoints faster. This package lets Scout-backed search accept dynamic, request-driven filter/sort parameters without hand-rolling a filter parser. That directly compresses the estimate for "searchable list with filters" features, which otherwise tend to become a multi-sprint side quest inside a CRUD screen.
• Build vs. buy for search plumbing. The decision is rarely "which search engine" — it's "do we maintain our own query-string-to-search-DSL layer?" This package is the buy answer for the translation layer, and the 1.2.0 changes strengthen the case by making that layer tolerant of malformed input rather than brittle.
• Roadmap: faceted filtering without a rewrite. Because filters are declarative and driver-agnostic (Scout), adding new filterable attributes later is a config/schema change rather than a new endpoint. Worth planning filterable attributes as a product surface (URL-shareable filter state) rather than an implementation detail.
• Risk posture on untrusted input. 1.2.0 specifically hardens two noisy edge cases: fully ignored nullable filters are skipped instead of applied, and unrecognized dynamic operator tokens fall back to equality instead of erroring. Translate that into a product decision: filtered URLs can be exposed to users, crawled, and shared with a much lower chance of a 500 or a confusing empty result set.
• Support-cost modelling. Graceful degradation on unknown operators means fewer "the filter link is broken" tickets and less defensive validation code on our side. That's a real, quantifiable line in the support budget for a search-heavy product.

When to Consider This Package

Consider adoption when:

• The application already uses Laravel Scout and one of its drivers; the package is a thin layer, not a replacement engine.
• Product requirements are request-shaped filters — query params, shareable/searchable URLs, admin table filters — rather than programmatic query construction.
• The team wants one conventions-based filter syntax across endpoints instead of bespoke when($request->has(...)) chains per controller.
• You need nullable/optional filters to behave predictably (a null or absent filter means "no constraint", not "match null"), which is exactly what 1.2.0 tightens up.
• You want to keep the search DSL out of the domain layer, so swapping Scout drivers stays an infrastructure concern.

Look elsewhere when:

• You need facets, aggregations, relevance tuning, or highlighting as first-class product features — that lives in the engine and its own SDK, not here.
• Requirements call for complex boolean/nested query composition or engine-specific operators; a generic token-based filter DSL will fight you, and 1.2.0's fallback-to-equality behavior signals that unknown operators are tolerated, not supported.
• You are not on Scout, or are on a driver whose filtering semantics differ enough that portability is an illusion — verify against your actual driver before committing.
• You need strict validation with loud failures on malformed filters. The new graceful-degradation default is good for users, but it can mask a typo'd operator in development; plan for validation at the request layer if that matters.
• Your search surface is small and static (a handful of fixed filters) — plain Scout where clauses are less machinery for the same outcome.

How to Pitch It (Stakeholders)

To executives: This is a small, focused dependency that removes the need to build and maintain our own search-filtering layer. It shortens time-to-market for filtered search screens by replacing custom parsing code with a convention, which means less code we own, fewer bugs, and cheaper iteration when product asks for "one more filter." Release 1.2.0 is a maintenance release that makes the layer more forgiving of malformed filter input — translating to fewer user-facing errors and lower support load, not new surface area.

To engineering: It's a declarative filter/sort builder for Laravel Scout — request params in, engine query out — keeping the search DSL out of controllers and domain code. 1.2.0 is a non-breaking minor: ignored nullable filters are now skipped rather than silently narrowing results, and unknown dynamic operator tokens fall back to equality instead of throwing. Both changes reduce edge-case failures on user-supplied URLs. The tradeoff to be aware of is that bad operators now degrade quietly, so request-level validation remains our responsibility. Low integration cost, low blast radius, and it keeps a driver swap as an infrastructure decision rather than a rewrite.