Http Query String Filter Bundle Laravel Package

Product Decisions This Supports

• Framing the "query string contract" as a product surface. This package encodes a real product concern: which query parameters an API accepts, what type they become, and who is allowed to filter on them. That maps directly to decisions about public API ergonomics, filter/sort/search capabilities on list endpoints, and pagination contracts — the areas where customer-facing behavior is hardest to change later.
• Build vs. buy for parameter validation and casting. It's a candidate "buy" (MIT, small surface area) for the narrow slice of work that is validating, casting, and authorizing query params before they reach a repository or query builder. If your team is writing the same filter_var / whitelist / cast boilerplate for the third time, this is the category of dependency that removes it.
• Use cases it plausibly serves: admin and reporting list views with many optional filters; internal APIs where filter whitelisting is a security control, not just convenience; multi-tenant endpoints where authorization must gate which fields a caller may filter on (e.g., tenant A cannot filter by another tenant's IDs).
• Roadmap implication — negative signal. Last release March 2016, 5 stars, 0 dependents, and a low health score. For a PM this is a decision to not adopt unless the constraint is "we must ship this filter layer in the next two sprints and we accept rewrite risk." Treat it as a reference design, not a dependency.
• Platform mismatch is a first-order decision. Despite being filed under "Laravel/PHP package," this is a Symfony bundle (*Bundle namespace, service-container wiring). In a Laravel codebase it does not install or wire up cleanly; adopting it means either a Symfony service in a Laravel app (awkward) or reimplementing the same ideas. That alone usually settles the build-vs-buy question.

When to Consider This Package

Consider it only when all of the following hold:

• The application is Symfony, on a PHP version the bundle actually supports (its 2016 vintage implies PHP 5.5–7.x era constraints; verify composer.json before promising anything).
• You need a thin declarative layer for whitelisting, type-casting, and authorizing query parameters, and you are comfortable pinning an unmaintained dependency or vendoring/forking it.
• The filter surface is small and stable — a handful of list endpoints — so the blast radius of a future rewrite is contained.
• You have someone who can own the fork: security patches, PHP 8.x compatibility, Symfony 6/7 attribute or config updates.

Look elsewhere when:

• You are on Laravel. Use spatie/laravel-query-builder (actively maintained, filter/sort/include conventions, strong docs) or hand-rolled FormRequests plus a query-builder scope. Both are better supported and cheaper to hire for.
• You need ongoing security maintenance. Query-param authorization touches injection and data-exposure boundaries; an eight-year-dormant package is a poor place to hold that responsibility.
• Your filtering needs are non-trivial — nested/relational filters, full-text search, faceting. That's a search layer (Meilisearch/Typesense/Elastic) or a mature query-builder package, not a parameter caster.
• You need team-scalable conventions. Zero dependents means zero community answers, zero third-party tutorials, and no Stack Overflow surface — a real onboarding tax.

How to Pitch It (Stakeholders)

For executives (30 seconds): A small open-source PHP component that standardizes how our APIs accept filters in URLs — what parameters are allowed, what type they are, and who may use them. It solves a real, recurring problem: ad-hoc filter parsing is where inconsistent behavior and data-leak bugs come from. However, this specific package is a Symfony component last updated in 2016, with effectively no user base, and it does not fit our Laravel stack. Recommendation: do not adopt as a dependency. Use it as a reference design and adopt a maintained alternative or a ~1-week internal implementation. Value delivered either way; risk avoided.

For engineering: The problem is worth solving deliberately — parameter whitelisting, casting, and per-field authorization belong in one place, not scattered across controllers. The package is not: it's a Symfony bundle, dormant since 2016, PHP-version-capped, unpatched, and with no dependents to lean on. Proposed path: (1) document our filter contract; (2) adopt a maintained Laravel query-builder package or write a small, tested filter/authorization layer (~200–400 LOC); (3) add contract tests per endpoint so filters are verifiable and safe to extend. Budget: roughly one sprint for the internal option, less if a maintained package covers our cases.

Ask: Approval to close this as "evaluated, not adopted," and to allocate a sprint to the filter-contract work so list endpoints stop diverging.