Product Decisions This Supports
- Build vs. buy vs. borrow for a recurring capability. Dynamic filtering (query-string → Eloquent constraints) is a horizontal need that reappears in every admin panel, list view, dashboard table, and public API collection endpoint. This package represents the "borrow" option: a small, MIT-licensed implementation you can adopt or vendor instead of speccing a ticket for each new filter UI.
- Roadmap sequencing for list/search experiences. If filtering is treated per-feature, every table view carries its own bespoke query-param handling and its own QA pass. Deciding to standardize filtering as a platform capability (one convention, one place to change it) shifts effort from N features to 1, and this package is a candidate artifact for that decision.
- API contract and query-parameter conventions. Filters become part of your public surface:
?status=active&created_after=2024-01-01 is a promise to clients, docs, and SDKs. Choosing this package is implicitly choosing a convention (and a validation posture) that's expensive to revise later — a decision worth making deliberately, before the first external consumer integrates.
- Time-to-market on internal tooling. For back-office, support, and ops dashboards, the user value is entirely in "can the ops team slice the data." A package like this can compress a multi-day backend task into hours, which matters when the feature is unglamorous and perpetually deprioritized.
- Maintenance and dependency-review decisions. With 0 stars, 0 dependents, a single maintainer, and a last release of April 2022, adoption is a bet on an unmaintained artifact against several Laravel and PHP majors of drift. The PM decision here is not "is the feature good" but "do we accept ownership of this code path," and the answer should be an explicit fork-and-own or decline, not a default
composer require.
- Where it should not drive a decision: anything user-facing at scale, anything behind an SLA, and anything a security questionnaire or SOC 2 dependency inventory will touch. Those routes go to a maintained alternative or a first-party implementation.
When to Consider This Package
Reasonable to evaluate when:
- The consumer is internal (admin panel, support console, ops dashboard) where a filter bug is an annoyance rather than a customer-facing incident.
- Your stack is pinned near the Laravel/PHP versions this package was written against, and you've confirmed compatibility rather than assumed it.
- The codebase is small enough to audit in an afternoon — read it, confirm it does what it says, and be prepared to fork and own it rather than depend on upstream releases.
- You want a reference implementation of the pattern more than you want a dependency; the design is the deliverable, and you re-implement it as a local trait or query scope.
- Your team is small and the alternative is "no filtering at all this quarter."
Look elsewhere when:
- The endpoint is public or contractually stable, and you need documented, versioned behavior and a maintainer who answers security reports.
- You need relational/nested filtering, AND/OR grouping, allow-listed sort + include params, or cursor-aware filtering — this package's "fully dynamic" framing is a feature for prototypes and a mass-assignment-style risk in production, since arbitrary query strings mapping to query constraints demand a strict allow-list that you must verify exists.
- Your org runs dependency review, SBOM, or vendor-risk processes — a zero-adoption package with no release in years will not clear them, and arguing for an exception costs more than writing the scope yourself.
- Buy (or use) the maintained option where the capability is load-bearing:
spatie/laravel-query-builder for allow-listed filtering/sorting/includes on APIs, or TuckerEricsson/eloquent-filter for a similar filter-class pattern with an actual user base.
- Your honest estimate of "just write the filter scope ourselves" is under a day — at that point the dependency is pure liability with no leverage.
How to Pitch It (Stakeholders)
To executives: This is a small, MIT-licensed PHP library that turns URL query strings into database filters, so we can ship filterable tables and list views on internal tools in hours instead of days. The upside is time-to-market on low-glamour internal features; the downside is real and specific — the project has no meaningful adoption, no releases since April 2022, and a single maintainer, so we would be taking ownership of the code. My recommendation is not to adopt it as a trusted dependency. Instead, treat it as a reference design: we read it, replicate the ~day of work it represents inside our own codebase, and keep our dependency surface clean. That gives us the delivery speed without adding a supply-chain and maintenance risk that nobody is funded to carry. For anything customer-facing, the maintained option is spatie/laravel-query-builder, and that's the only variant I'd ask you to fund a decision on.
To engineering: The pattern is worth stealing; the dependency isn't. Filter params become a public contract and a query-constraint surface, so the two things we must get right are allow-listing (never interpolate raw query keys into column names or operators) and one convention across endpoints so we don't re-litigate it per feature. Proposal: one local trait or query-scope layer, an explicit allow-list per model, tests around it, and no new Composer entry. If you'd rather not hand-roll, go to spatie/laravel-query-builder — maintained, documented, and it already encodes the allow-list discipline we'd otherwise have to invent. We should also record the decision, so this doesn't resurface every time someone finds a new filter package.