Filter Bundle Laravel Package

Technical Evaluation

Architecture fit — fundamental mismatch. sidus/filter-bundle is a Symfony bundle, not a Laravel package. Bundles are a Symfony packaging contract: a Bundle subclass, a DependencyInjection\Extension with a Configuration tree, compiler passes, and tag-driven service discovery (sidus.filter.query_handler-style tags). Laravel has no bundle concept and no compiler pass stage — its container resolves bindings at runtime through service providers. Installing the bundle into Laravel is not "add a provider"; it means booting Symfony's HttpKernel/FrameworkBundle inside an Illuminate application, which is an anti-pattern with a long tail of failure modes (duplicate request stacks, container isolation, config caching conflicts).

What is actually reusable. The domain layer described — immutable filter/sort/pagination definitions plus per-request query handlers — is the valuable part and is orthogonal to Symfony. If the package has genuinely split a provider-agnostic core from the Doctrine ORM adapter (the description implies it), the core is plain PHP value objects and interfaces, portable to Laravel. The Doctrine provider is not portable: Eloquent is not a Doctrine QueryBuilder, and there is no Eloquent provider.

Integration feasibility. Three paths, in descending order of sanity:

1. Reject the dependency, copy the pattern. Reimplement immutable filter definitions + handler-per-request in ~500–800 LOC under app/Filtering. Two to three weeks for one senior engineer including tests. You own it, but you own a small thing.
2. Vendor/fork the core namespace only. Strip Symfony/Doctrine coupling, keep value objects and handler interfaces, write an Eloquent handler. One to two week spike, then permanent fork maintenance.
3. Bridge Symfony components into Laravel. High effort, no upside, and it makes every future Laravel upgrade a negotiation with a dead package. Not advised.

Technical risk — high, and mostly non-technical.

• Abandonment. Last release 2021-06-15; four-plus years without a tag. Single maintainer, no evidence of an active fork.
• Bus factor of one, with zero community. 1 star / 0 dependents means no downstream users to file issues, no Stack Overflow corpus, no blog posts, no third party who has hit your bug before you.
• Composer constraints. A 2021 tag almost certainly pins php ^7.4|^8.0 and symfony/* ^4.4|^5.x. Laravel 10/11/12 requires PHP 8.1+/8.2+. Dependency resolution will likely fail outright on a modern app — which is at least a loud, early failure rather than a silent one.
• No security process. No advisories to date because nobody is looking. A filter-to-query translator is exactly the class of code where an unvalidated sort column becomes SQL injection or an index-defeating DoS.

Key questions to answer before any code is written:

• Is the provider-agnostic core a separate package (sidus/filter) or a namespace inside the same composer package as the Symfony glue? This single answer determines whether option 2 exists.
• What are the exact composer.json require constraints for php, symfony/*, doctrine/orm?
• Does the core reference Symfony\Component\HttpFoundation\Request (request-coupled handlers) or take a plain DTO?
• What is the LOC of the core, and what test coverage ships with it?
• Is the documentation complete and in English?

Integration Approach

Stack fit — poor as-is, workable after excision. Laravel's idiomatic equivalents are FormRequests for input validation, query scopes / Illuminate\Database\Eloquent\Builder for composition, and resource classes for output. Sidus's idiom — a registry of tagged query handlers resolved per request against an immutable filter set — maps cleanly onto Laravel middleware + a container-tagged handler registry, but nothing does that mapping for you.

Migration path. Do not attempt to run the bundle. Vendor the core domain objects into app/Filtering/, preserving the design intent:

• Immutable definitions (FilterSet, Filter, Sort, Pagination) as readonly value objects, constructed once per request.
• A request parser in a FormRequest or middleware that validates allowed filter/sort keys against the definition before anything reaches the builder.
• An EloquentQueryHandler implementing the ported handler interface, applying where/orderBy/paginate from the definitions.
• A registry bound in a service provider, resolving handler → definition by resource key (mirrors the tagged-service behaviour).

Compatibility gates. Check the PHP constraint first — if it excludes 8.1+, stop and go to option 1. Check whether doctrine/orm is a hard require rather than a suggest; if it is, the package drags a full ORM into a Laravel app for no reason. Check the PSR compliance of the core interfaces (PSR-7/PSR-15 cleanliness is a good proxy for portability).

Sequencing.

1. Half-day spike: composer require in a throwaway Laravel 11 app. Note whether it resolves; if it does, grep -r "Symfony\\\\" vendor/sidus to measure coupling.
2. Read the core. Estimate LOC and test coverage; identify the exact seam between core and Doctrine provider.
3. PoC: port the value objects, wire one Eloquent handler against one real resource. Timebox to three days.
4. Benchmark against alternatives — Spatie Query Builder (actively maintained, Laravel-native, MIT) and a hand-rolled 600-LOC implementation. Be explicit that Sidus's genuine differentiator is immutable, pre-declared filter definitions, which buys you validation-by-construction; if that property isn't worth the fork, Spatie wins on every other axis.
5. Decide fork vs build, then commit either way — the worst outcome is a half-vendored dependency nobody owns.

Operational Impact

Maintenance — you inherit the whole thing. No upstream releases means no upstream fixes: PHP 8.3/8.4 compatibility, Laravel major bumps, and any security issue are yours. Budget roughly 5–10% of one engineer per quarter for a forked core, plus the one-off port. MIT licensing makes the fork legal and frictionless; retain the copyright notice.

Support — effectively zero. No maintainer SLA, no issue triage cadence, no community to ask. Documentation is whatever is in the repo, and given the author's background, portions may be French-language or terse. Every onboarding engineer pays a research tax that a 1-star package cannot amortize.

Scaling. The runtime design is sound — immutable definitions are cheap, and cost lives in query construction, not the library. Real scaling risks are data-shaped:

• Sort whitelisting is mandatory. Unsorted/unindexed ORDER BY on a user-supplied column is both an injection vector and a table-scan DoS.
• Page-size caps. Enforce a maximum in the request parser, not the handler.
• Offset pagination. Likely LIMIT/OFFSET; deep pages degrade badly on large tables. Plan for cursor pagination on the biggest lists, which you will have to add yourself.
• Join explosion. Filters spanning relations invite N+1 and duplicate rows; distinct and eager-load strategy must be part of the handler, not an afterthought.

Failure modes, ranked by likelihood:

1. Composer refuses to resolve on PHP 8.1+ — loud, early, harmless. Most likely.
2. Unvalidated filter keys reach the builder — silent, dangerous.
3. A transitive symfony/* or doctrine/* pin drags the app backward and blocks a Laravel/PHP upgrade — slow-burning, expensive.
4. Upstream tag is force-pushed or deleted with no SemVer discipline — low probability, but a fork makes it irrelevant.

Ramp-up. One to two days for a senior Laravel engineer to absorb the core concepts; the Symfony DI idiom adds perhaps a day of confusion before it's discarded. The durable ramp-up cost is organisational, not technical: someone must be named owner of the fork, with CI, a PHP 8.1–8.4 × Laravel 10–12 test matrix, and a documented upgrade ritual.

Recommendation. Do not adopt as a runtime dependency — the Symfony/Laravel impedance mismatch is structural and the package is four years unmaintained with no user base. The pattern (immutable definitions, per-request handlers, validated-before-execution) is genuinely good and worth copying into 500–800 lines of owned Laravel code, or buying from Spatie Query Builder if the immutability guarantee isn't essential to your domain.