Eloquent Filter Laravel Package

Product Decisions This Supports

• Filterable collection endpoints as a product capability. This package is a candidate implementation for a recurring feature request: letting users narrow list views and API collections via URL query strings (?filter[status]=active&filter[owner_id]=…). It informs the roadmap decision of whether filtering is a shared platform capability or per-endpoint hand-coding.
• API query-string contract design. Whatever we ship defines a public, versioned contract (param naming, nesting, operator syntax, behavior on unknown keys, pagination interaction). That's a product/API decision with backward-compatibility consequences — URL shareability, saved views, and deep links all depend on it.
• Build vs. buy for a generic concern. Filtering is plumbing, not differentiation. This package represents the "buy" option; the assessment below is really a recommendation to not buy and to instead build a thin in-house layer or adopt a maintained alternative.
• Scoping for adjacent features. The same layer underpins admin dashboards, exports, saved filters, reporting/segment builders, and CSV/PDF output. Deciding on it unblocks or constrains all of those.
• Risk posture for dependency intake. 22 stars, 0 dependents, and an archived repository make this a concrete test case for our dependency-vetting policy (maintenance status, security patch path, framework-version support).

Recommendation: do not adopt for production. Use only as prior art.

When to Consider This Package

Consider it only as:

• Reference material / prior art when designing our own filter syntax — read the parameter conventions, then discard the code.
• A throwaway prototype (internal spike, demo, one-off script) where the code never reaches production, never handles untrusted input, and is expected to be deleted within weeks.
• A legacy-pinned context where the app is frozen on an old Laravel version, the package is already installed and working, and there is no security exposure — accept it as technical debt, do not expand its use.

Look elsewhere — or build — if any of these hold:

• The feature is customer-facing, long-lived, or security-reviewed. An archived package has no patch path; a future Laravel major or a filtering-related vulnerability leaves us forking.
• We need framework-version currency (Laravel 10/11/12) or PHP 8.2+ support.
• We need the full surface: allowlisted filters, sort + pagination interplay, relationship/eager-load filters without N+1, nested boolean logic, per-tenant scoping, and documented behavior for malformed input.
• We need community validation — 0 dependents means no production signal; we'd be the first.
• We need OpenAPI/contract documentation and test coverage we can rely on.

Preferred path: evaluate spatie/laravel-query-builder (actively maintained, allowlist-first by design, very high adoption) against a ~1–2 week in-house trait. For most teams the in-house option wins: filtering is ~200 lines, it eliminates the dependency entirely, and it lets us enforce allowlisting and tenant scoping by construction.

How to Pitch It (Stakeholders)

To executives: We found a package that would deliver filterable lists and API endpoints quickly, but it's been archived — it receives no updates or security fixes, has no downstream users, and would become something we own and maintain without having chosen to. The time saved up front (roughly one to two weeks) is smaller than the cost of a mid-flight migration or a security finding later. Recommendation: build a small in-house filtering layer, or adopt the maintained market-standard package, at comparable near-term cost with materially lower long-term risk. Net: no material schedule impact, significantly better risk position.

To engineering: Evaluate as a spec, not a dependency. The archived status and zero dependents mean no upstream fixes for framework upgrades, no security response, and no community triage. Whichever implementation we choose must: allowlist every filterable field and relation explicitly (no client-driven column access), reject or ignore unknown params deterministically, scope by tenant/authorization at the query layer, avoid N+1 when filtering on relations, and keep the query-string contract documented and versioned. Deliverable: a short spike comparing spatie/laravel-query-builder against an in-house trait, with the contract spec — decision within one sprint.

Bottom line: Reject for production adoption; retain as design input. Fund a one-week spike, then commit to a maintained or in-house filtering layer.