Laravel Sieve Laravel Package

Product Decisions This Supports

• Build vs. buy for a cross-cutting concern. Filtering and sorting show up in nearly every list endpoint (admin tables, APIs, exports, dashboards). Each sprint team either rebuilds it or hand-rolls a new scopeFilter() variant. A package like this turns a repeated build cost into a one-time adoption decision.
• Time-to-market on admin/back-office surfaces. Whitelisted, declarative filters let a small team ship CRUD screens and public list APIs faster, and make "add a filter for X" a config change rather than a code change — directly compressing roadmap estimates for internal tooling work.
• API contract standardization. A consistent query-parameter grammar (?filter[status]=active&sort=-created_at) is a product-level decision: it becomes a documented, versioned contract for customers and integrations. Standardizing early avoids a painful breaking change later.
• Security and data-exposure posture. Ad-hoc filtering is where SQL injection, unindexed full-table sorts, and unauthorized column access creep in. A package that requires explicit allow-lists converts an open-ended risk into a reviewable, enumerable surface — a genuine product-risk reduction, not just a DX nicety.
• Prioritization of search features. If the roadmap is heading toward faceted search, relevance ranking, or aggregations, this package is a stepping stone, not the destination. The decision here gates whether you invest in query-param filtering now or jump straight to a search backend.
• Buy-vs-build on maintenance ownership. Adopting a 14-star, single-maintainer, zero-dependent package means your team owns the fork in practice. That's a resourcing decision, not just a technical one.

When to Consider This Package

Consider it when most of the following hold:

• You are on a current Laravel version and your filtering needs are conventional: equality, ranges, LIKE, date bounds, relation filters, and sortable-column allow-lists.
• You want an expressive, reusable filter layer and are prepared to wrap it behind an internal interface (your own base filter class or adapter) so it can be swapped without touching controllers.
• Your team is small and the alternative is bespoke filter code duplicated across a dozen controllers.
• You can pin the version, review the source (it's small enough to audit in an afternoon), and accept the bus-factor risk.
• Filtering is a supporting capability, not your product's differentiator.

Look elsewhere — or build in-house — when:

• Ecosystem validation is a hard requirement. With 14 stars and 0 dependents, there is no community track record. spatie/laravel-query-builder occupies the same problem space with orders of magnitude more production exposure; that comparison should be made explicitly, not skipped.
• You need search-grade capability. Facets, aggregations, typo tolerance, relevance, or sub-100ms filtering over millions of rows belong to Scout + Meilisearch/Typesense/Elasticsearch, not an Eloquent query-builder wrapper.
• You need permission-aware or tenant-aware filtering as a first-class concern. Row-level scoping tied to roles usually needs to live in your domain layer, not a generic filter package.
• Compliance or procurement requires vendor support, SLAs, or a maintenance commitment. None exist here.
• The package goes unmaintained. Set a review trigger: no release in 12 months, or an unresolved issue against a new Laravel major, means fork it or migrate off.

How to Pitch It (Stakeholders)

For executives: List, search, and filter screens are a recurring cost across our roadmap — every team rebuilds them slightly differently, and each rebuild carries a small but real security risk. This package is a lightweight, allow-list-driven way to standardize that layer and make "add a filter" a configuration task instead of engineering work. The trade-off is honest: it is a young, single-maintainer open-source library with no meaningful adoption yet, so the recommendation is a time-boxed evaluation and pilot on one non-critical surface — not a platform-wide commitment. We would wrap it behind our own interface so the exit cost stays low. Success criteria: pilot ships faster than the in-house estimate, and the abstraction holds without leaking into controllers. If it fails either, we fall back to the better-established Spatie package or a small internal module.

For engineering: Thin abstraction over Eloquent and the query builder for declarative filters and sorts. The value is the allow-list model — sortable and filterable columns become explicit, auditable config rather than string concatenation — plus removal of duplicated scope logic. It is small enough to read end-to-end before adopting. Adopt behind an internal adapter, pin the version, and treat the fork as ours if upstream stalls. Benchmark against spatie/laravel-query-builder before deciding; the star gap is a signal about maintenance risk, not necessarily about API fit. Watch for the usual traps: unindexed sort columns, relation filters causing N+1s, and filter keys that don't map to permitted fields.