Filter Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy on list/filter infrastructure. The package encodes a specific architecture — immutable, declarative filter definitions decoupled from per-request query handlers — which is the decision most teams actually face: do we hand-roll where clauses per endpoint, or invest in a filter specification layer? Sidus is a reference implementation of the "invest" answer, and its structure is worth evaluating even if the code isn't adopted.
• API surface consistency. If your roadmap includes many list endpoints (admin tables, search, exports, audit logs), a shared filter/sort/pagination contract reduces per-endpoint variation and makes filtering behavior predictable for front-end and partner integrations. This package's provider-agnostic handler split is a model for that contract.
• Backend portability. Supports filtering across multiple data providers (ORM/ODM/search index) behind one definition set. Relevant if the roadmap includes migrating a read path to a search engine without rewriting every endpoint's filter logic.
• Prioritization of filter features. Useful as a scope checklist: which filters are declarative vs. custom, how sorting and pagination interact with filters, whether filters are user-savable per request. Helps frame "saved views / saved segments" as a product feature rather than an engineering detail.
• Risk and total-cost-of-ownership decisions. With 1 star, 0 dependents, and a last release of June 2021, this is a decision against adoption as a dependency — but a decision for borrowing the pattern. That's a legitimate roadmap outcome and should be recorded as such.

When to Consider This Package

Consider it only under a narrow set of conditions:

• The stack is Symfony, not Laravel. Despite being catalogued as a "Laravel/PHP package," SidusFilterBundle is a Symfony bundle; using it in Laravel means bypassing the bundle wiring entirely, at which point you're consuming raw classes with no framework integration.
• You need a declarative filter specification pattern and are prepared to fork and own it — vendor the code, add tests, and accept maintenance as an internal cost center.
• You have multiple persistence backends for the same domain and genuinely need one filter definition to drive several providers.
• You have a team comfortable reading source as documentation; there is no meaningful community, no issue traffic, and no upgrade path.

Look elsewhere when:

• You're on Laravel/Eloquent. Use spatie/laravel-query-builder, API Platform filters (Symfony), or a thin internal layer. These have active maintenance, documentation, and an answerable support channel.
• You need security patching or long-term support. A package last released in mid-2021 with no dependents will not receive CVEs or PHP-version compatibility fixes. That's a hard blocker for anything customer-facing or regulated.
• You need pagination/serialization integration. This package is a filter layer, not a full query pipeline; expect to build the surrounding pieces yourself.
• Your filter needs are modest. If you have under ~10 list endpoints and simple filtering, a small internal trait/scope set is cheaper than any dependency, including a healthy one.
• You need community-validated behavior. One star and zero dependents means zero field testing outside the author's use case.

How to Pitch It (Stakeholders)

Recommendation: do not adopt as a dependency; use it as a design reference and build or buy a maintained alternative.

SidusFilterBundle offers a clean, well-reasoned model for list filtering — immutable filter definitions separated from per-request query handlers, with a provider-agnostic core. That separation is genuinely good architecture and worth citing when we design our own filtering layer.

As a dependency, however, it fails basic due-diligence thresholds: 1 GitHub star, 0 dependent projects, no release since June 2021, and it's a Symfony bundle rather than a Laravel package, so we'd get no framework integration out of the box. Adopting it means we own the code, the tests, and all future PHP-version and security maintenance — a permanent tax for roughly 300–500 lines of logic we could write or configure ourselves.

For engineering: treat it as a pattern reference. Evaluate spatie/laravel-query-builder for the Eloquent path against a 1–2 day spike on one representative endpoint; measure it against our actual filter complexity (nested relations, multi-tenant scoping, sortable whitelists).

Cost framing: a fork carries an estimated ongoing maintenance load of several days per year plus unbounded risk on framework upgrades; a maintained dependency carries near-zero, and a thin in-house layer carries a one-time cost of roughly one sprint.

Decision requested: approve the spike, and close the question of adopting unmaintained single-maintainer packages for core query infrastructure as a matter of policy.