Filter Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for list/search endpoints. The capability in question — turning HTTP query parameters into Doctrine QueryBuilder filters for admin lists, faceted search, exports, and reporting views — is a recurring backlog item on nearly every CRUD-heavy product. This package is one candidate implementation, and evaluating it forces an explicit build-vs-buy call.
• Dependency and tech-debt triage. If this appears anywhere in an existing composer.json, it becomes a migration line item ahead of any PHP or Symfony major upgrade. If it does not, the decision is a fast "no" and should be closed rather than parked.
• Vendor-risk policy validation. Archived since February 2018, zero stars, zero dependents, no maintainer response path. It is a useful concrete example when arguing for a minimum bar (maintenance status, release recency, dependent count) in the dependency approval checklist.
• Use-case scoping, not feature selection. It clarifies which of our surfaces actually need server-side filtering (back-office tables, export jobs, partner APIs) versus client-side filtering, and how much of that is permission-aware — a requirement this bundle predates entirely.
• Roadmap capacity signal. An opportunity score of 5.87 with zero adoption says the market has commoditized this problem. It should not consume roadmap time; the correct output of this assessment is "no action."

When to Consider This Package

Consider only in these narrow cases:

• You are inventorying an existing Symfony 3.x/4.x codebase and need to understand what a legacy filter layer does before replacing it.
• You are writing an internal design doc and want a historical reference implementation of request-parameter-to-query filtering.
• You are explicitly willing to fork under MIT and own maintenance indefinitely — which is a build decision wearing a buy costume, and should be staffed as such.

Look elsewhere — or build — in every other case:

• Wrong framework. This is a Symfony bundle. It will not install or function in Laravel. If the framing of the request is "Laravel package," stop here: the evaluation is moot.
• Greenfield or actively maintained services. Eight years without a release means no PHP 8.2+ guarantees, no Doctrine 3 compatibility, no security response, and no one to answer an issue.
• Non-negotiable requirements. Permission-aware filtering, full-text search, faceted aggregations, stable filter-parameter contracts, and testability are all outside what a 2018 bundle was designed to deliver.
• Any team without spare Symfony-internals capacity. The cost of reading and owning unfamiliar abandoned code typically exceeds the one-to-two weeks needed to write a focused DTO-plus-QueryBuilder filter layer that the team controls.

How to Pitch It (Stakeholders)

For executives. This is a small, abandoned Symfony component for converting URL query parameters into database filters — a commodity capability, not a differentiator. It has no users, no maintainer, and no release since early 2018. My recommendation is to not adopt it and to remove it from any active backlog. Adopting it would buy us roughly one to two weeks of engineering while adding permanent security-review and upgrade exposure with no support path. The build alternative is small and fully within our control. No budget, no headcount, no roadmap change required.

For engineering. The underlying pattern — declarative, request-driven filtering over Doctrine query builders — is worth having in our toolkit. This specific implementation is not the way to get it. It is Symfony-only, written for a PHP and Doctrine generation that predates attributes and Doctrine\ORM 3, and it is archived with a sole-maintainer history. If we need this capability in a Symfony service, evaluate API Platform's filter system or DoctrineExtensions' query-builder filters, or write a ~200-line DTO plus QueryBuilder layer — which has the added benefit of being permission-aware and straightforward to unit test. If this came up as an existing dependency, classify it as a migration item ahead of the next major upgrade, not a foundation to build on. If the question originated from a Laravel team: the premise does not apply, and there is nothing to evaluate.