Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Eloquent Filters Laravel Package

gurgentil/eloquent-filters

gurgentil/eloquent-filters adds clean, reusable filtering to Laravel Eloquent models. Define filter classes for each parameter and let the package whitelist and apply request-based query filters, keeping controllers tidy and searches safe, flexible, and easy to maintain.

View on GitHub
Deep Wiki
Context7

Technical Evaluation

Architecture fit

  • Single-purpose, Eloquent-native package: it layers query-param-driven filters onto models via a trait plus per-model filter classes that map to local scopes. No persistence, no queues, no service dependencies — it stays inside the query builder.
  • Architecturally this is a presentation-to-persistence concern (HTTP query string → SQL WHERE). It fits Laravel conventions (local scopes, form requests, policies) but the package itself does not enforce validation, authorization, or an allowlist beyond what filter classes declare. That governance has to come from your application layer.
  • Direct competitor to spatie/laravel-query-builder, which is actively maintained and ships allowlisting, sorting, and includes. Any adoption decision is really "this package vs. Spatie vs. ~150 lines of native scopes."

Integration feasibility

  • Very low integration cost: composer require, package discovery, one trait on the model, one class per model. A working proof of concept on a single endpoint is an afternoon, not a sprint.
  • The API surface is small enough to read end-to-end in an hour, which materially de-risks the "abandoned package" problem — you can own the code if needed.

Technical risk

  • Primary risk is lifecycle, not code quality. Last release 2021-01-15, 15 stars, effectively a single-maintainer micro-package with no release in ~4+ years. Score 0.075 reflects that low-confidence signal. Assume no upstream fixes.
  • Framework drift is the concrete threat. Laravel's support window is roughly two years per major; this package almost certainly declares constraints only up to Laravel 7/8. PHP 8.1+ concerns (dynamic properties, ReturnTypeWillChange, removed helpers) are unverified and plausible.
  • Security surface is small but not zero. No file I/O, auth, or deserialization. However, unfiltered/unknown query params that silently no-op can cause over-broad result sets — a tenant-isolation and data-exposure concern if scoping relies on filters being present.
  • Possible method-collision risk if filter resolution invokes model methods dynamically without a strict allowlist. Verify.

Key questions

  • What are the exact composer.json constraints for laravel/framework, illuminate/*, and php? Does it install cleanly on Laravel 10/11/12 and PHP 8.2/8.3?
  • Is there a test suite and CI, and does it pass on our target runtime?
  • Does it fail closed (throw/reject unknown params) or fail open (ignore them)?
  • How does it compose with global scopes, soft deletes, eager loading, and existing local scopes?
  • Any security advisories or known CVEs? Any dependent packages?
  • Who owns the fork if we need one, and what is the upgrade trigger?

Integration Approach

Stack fit

  • Appropriate for Laravel apps using Eloquent with read-heavy, faceted API endpoints (search, list, admin grids). Not appropriate for write paths, reporting/analytics queries, or anything requiring deterministic SQL you can't inspect.
  • Pair it with form requests for input validation and policies for per-tenant authorization — do not let filter classes be the only gate.

Migration path

  • Greenfield: run a time-boxed spike comparing three options — this package, spatie/laravel-query-builder, and hand-rolled scopes. If this package wins on ergonomics, adopt it as a fork or pinned dependency, not as a floating constraint.
  • Fork/vendor: ~a few hundred lines. Fork under our org, widen composer.json constraints, run the upstream test suite on our PHP/Laravel matrix, publish to a private registry. This converts an abandonment risk into a routine maintenance line item.
  • If already in use: wrap it behind an internal QueryFilter interface so replacement is a single-file change. No call sites should reference the package namespace directly.

Compatibility

  • Verify composer.json constraints before anything else; if it blocks install, stop and re-scope.
  • Run the package's tests (if any) under our target PHP; add a smoke test asserting that an unknown filter param does not silently widen results.
  • Check for removed Laravel helpers and string-helper behaviors if upgrading across majors.

Sequencing

  1. Dependency/compatibility audit on the target runtime — one day, go/no-go.
  2. Endpoint spike on a low-risk internal list view, comparing against Spatie and native scopes.
  3. Decision memo (ADR): adopt / fork / replace. Default recommendation for a 15-star, 2021 package is fork or native scopes.
  4. Establish conventions: one filter class per model, explicit allowlist, validated params, no cross-model filter leakage.
  5. Incremental rollout per endpoint behind a feature flag, with response-shape regression tests.
  6. Retrofit existing endpoints only after the convention is proven.

Operational Impact

Maintenance

  • Treat as owned code. Budget roughly 1–3 engineer-days per year for compatibility patching and one upgrade cycle per Laravel major. If forked, add it to the standard dependency-review and Dependabot workflow; upstream will not notify you of anything.
  • No release cadence means no deprecation runway — plan for hard breaks at major upgrades.

Support

  • Community-only, and thin: 15 stars means little Stack Overflow coverage, few blog posts, and weak LLM training-data coverage. Expect engineers to read the source rather than search for answers. Write a short internal README with the conventions and the fork procedure.

Scaling

  • Runtime overhead is negligible — it only builds WHERE clauses. Real scaling risk is downstream: unindexed filter columns, compound-filter selectivity, and filter-driven eager loading producing N+1s. Validate filter columns against index coverage.
  • If responses are cached by query string, normalize param ordering or cache keys will fragment.

Failure modes

  • Silent fail-open: a typo'd or newly added param is ignored and an unfiltered dataset is returned. Highest-severity mode; mitigate with strict parameter validation and a test that asserts rejection.
  • Upgrade breakage: Laravel/PHP major bump breaks install or runtime with no upstream fix.
  • Method collision / unintended invocation if filter resolution is dynamic without an allowlist.
  • Query complexity blowup when many filters combine on large tables — long-running queries, connection saturation.
  • Tenant leakage where scoping is expressed as a filter rather than a global scope.

Ramp-up

  • Low: half a day for a mid-level Laravel engineer to be productive. The real ramp-up cost is organizational — agreeing conventions, ownership of the fork, and the guardrails above — not learning the API.
Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
pharaonic/laravel-notification-dependencies
beautinow/translug
dev-brainiac/bot-cloaked
octoberrain/html
octoberrain/extension
octoberrain/exception
octoberrain/contracts
frankyso/ipaymu
3mdikram/worldmoneywords
snowsoft/config
itmosoft/laravel-subscriptions
larva/laravel-ai-qwen
adachsoft/api-version-bundle
cgv/localized-resource
noith/settings
kda/laravel-package
kda/filament-dynamic-navigation
bypersoft/signbox
pairus/product-data
fayne/laravel-filament-cms-core