Product Decisions This Supports
- Build vs. buy for list/filter UX: This is a small, single-purpose package that standardizes how Eloquent models expose filtering, sorting, and search parameters. For teams deciding whether to hand-roll query-string filtering (a recurring 3–10 day build across each CRUD area) versus dropping in a maintained dependency, it shifts the decision toward "buy" for standard admin and reporting surfaces.
- Roadmap sequencing for data-heavy features: If the roadmap includes dashboards, audit logs, order/customer tables, or any "filter by status, date, owner, free text" surface, adopting this package early lets that work land without redesigning query layers later. It is a foundational utility, not a differentiating feature — it should be scheduled as enablement, not as a headline release.
- Scope control on internal tooling: Filtering/search requests are a reliable source of scope creep and inconsistent implementations (each team inventing its own
?q=, ?sort=, ?order= convention). Standardizing on this package caps that variation and reduces the spec surface for admin tooling.
- Feature-flag and API contract decisions: Because filtering is defined in code (a filter class per model), adding or removing a filter becomes a reviewable, testable code change rather than ad-hoc SQL. That makes it easier to ship filter changes incrementally behind flags and to keep API query-parameter contracts stable.
- Dependency governance and support-window planning: v2.0.3 adds Laravel 13 support. This is the only functional signal in the release and directly feeds the decision of whether this package can travel with the team's Laravel upgrade roadmap, or whether it becomes an upgrade blocker.
- Use cases it fits: internal admin panels, back-office CRUD, reporting list views, customer-facing "browse and refine" tables, and any endpoint where clients need to pass sort/filter parameters safely through Eloquent rather than raw SQL.
When to Consider This Package
Adopt when:
- The product has multiple (or expected to have multiple) list views over Eloquent models that need consistent filtering, sorting, and search.
- The team is on Laravel 10–13 and wants a small, low-ceremony dependency rather than a full search stack.
- Requirements are modest and relational: equality, ranges, date windows, LIKE search, multi-column sorting. No relevance ranking or fuzzy matching needed.
- You want the filter surface to be explicit and code-reviewed (which filters are allowed per model) for security and query-safety reasons.
- You value a narrow dependency: the release history is dominated by Dependabot bumps rather than churn, which suggests a stable, small API.
Look elsewhere when:
- Requirements include full-text relevance, faceting, typo tolerance, or large-scale aggregation — evaluate Laravel Scout with Meilisearch/Typesense, or Elasticsearch/OpenSearch.
- The data volume and query patterns need precomputed indexes, materialized views, or a dedicated analytics store.
- Your organization requires vendor-backed SLA support; this is a single-maintainer open-source package.
- You need complex nested boolean query UX (query builders with grouped AND/OR conditions) beyond what a filter-class approach cleanly expresses.
- The team already has an in-house filtering abstraction that is battle-tested — migrating carries cost without a clear payoff.
On this specific release (v2.0.3): it is a maintenance/patch release. All changes are dependency bumps (Symfony components, league/commonmark, phpunit, psy/psysh) plus explicit support for Laravel 13. No breaking changes, no deprecations, no new filtering capabilities. It is safe to take, and the Laravel 13 support is the item worth acting on — it removes a potential blocker from the framework upgrade path. The patch-level version bump is appropriate to the change.
How to Pitch It (Stakeholders)
For executives (30 seconds): We're evaluating a small open-source add-on that gives every list, table, and report in our Laravel applications a consistent way to filter, sort, and search. The alternative is paying engineers to rebuild that same plumbing repeatedly, differently, in each area of the product. The latest release (v2.0.3) is routine maintenance — dependency updates and compatibility with the newest Laravel version — with no breaking changes, so there is no migration risk and no new cost. The main trade-off is that it's maintained by a single open-source author rather than a vendor, so we should treat it as a convenience layer, not a critical-path dependency.
For engineering: This is dcblogdev/laravel-filters, a thin abstraction over Eloquent that lets you declare per-model filter classes and expose allowed filters, sorts, and search to a query string. v2.0.3 is a patch release: Dependabot bumps across Symfony HTTP foundation/process, league/commonmark, phpunit, and psysh, plus added Laravel 13 support. No API changes, no deprecations, no breaking changes — a safe minor-risk upgrade. Two things to note: the release keeps us current on transitive security patches for commonmark and Symfony components, and the Laravel 13 support keeps this dependency off the critical path for the framework upgrade. Recommended next step is a time-boxed spike: apply it to one existing list view, measure the diff in code volume versus our current hand-rolled filtering, and confirm the dependency footprint is acceptable before standardizing on it.