Api Filter Bundle Laravel Package

Technical Evaluation

Architecture fit — unchanged: the framing problem remains. Release 2.6.0 is maintenance-only for a Symfony bundle, not a Laravel package. The changes are Symfony/DI hygiene: replacing deprecated tagged wiring with tagged_iterator, converting DI XML config to PHP, PHP 8.4 deprecation cleanup, .gitattributes updates, and sandbox progress messages. None of that adds a Laravel service provider, Eloquent integration, or framework-agnostic packaging. From a Laravel application’s perspective, architecture fit remains low unless we treat the package as a reference implementation or grammar source rather than a dependency.

The reusable asset is still the filter/order parsing domain logic, contingent on how tightly it is bound to Doctrine QueryBuilder/DQL. 2.6.0 does not change that calculus.

Integration feasibility — three paths unchanged:

1. Adopt a Laravel-native equivalent such as spatie/laravel-query-builder, using this package only as a feature benchmark. Lowest risk, lowest ownership cost.
2. Fork and extract the filter/order grammar into a framework-agnostic package with an Eloquent criteria adapter. Viable only if the filter semantics are genuinely differentiated.
3. Install as-is via Composer. Still not viable in Laravel — no bootstrapping path, and the Symfony DI wiring would be inert.

Technical risk — provenance slightly improved; dominant risks unchanged. 2.6.0 is a positive maintenance signal: the maintainer is active and addressing Symfony/PHP deprecations, including PHP 8.4 awareness. That marginally lowers abandonment risk. It does not address the core concerns: zero dependents, likely bus factor of one, no Laravel version claims, no evidence of production adoption, and unverified test/CI coverage. The highest-severity functional risk remains the filterable/sortable field allowlist — unvalidated user input mapped to columns or operators can cause query errors, full-table scans, wrong results, or injection. Review the 2.6.0 diff to confirm whether any public filter/order API changed; the release notes suggest DI/internal maintenance only, but that must be verified. The earlier release-date metadata anomaly should still be checked against actual tag history, though 2.6.0 confirms ongoing publishing activity.

Key questions:

• Does 2.6.0 alter any public filter/order API, or only Symfony DI and sandbox internals?
• Is the filter grammar framework-agnostic, or hard-bound to Doctrine QueryBuilder/DQL?
• Is there a field allowlist, and is it mandatory or opt-in?
• What does the test suite cover, and does it run in CI?
• What are the actual Composer constraints for PHP and Symfony after 2.6.0?
• Are filter and ordering operators extensible, or fixed?

Integration Approach

Stack fit. Unchanged. The package targets Symfony HTTP + Doctrine query layers; our stack is Laravel HTTP + Eloquent. The mismatch is at the query layer. Request parsing is cheap to reimplement; query construction is where the useful logic and the risk sit. 2.6.0’s DI modernization is Symfony-only and does not improve Laravel fit.

Migration path. Fork or vendor a pinned copy → isolate filter grammar and criteria objects → strip Symfony DI and Doctrine compilation → implement an Eloquent criteria-to-builder adapter → cover with conformance tests. Pin to a commit SHA; do not take a floating constraint on a single-maintainer package. Review the 2.6.0 diff before pinning to confirm no behavioural or public API changes.

Compatibility. 2.6.0 shows attention to PHP 8.4 deprecations, which is a useful signal, but there are still no Laravel compatibility claims. Assume nothing about Laravel 10/11/12 support; verify Composer constraints explicitly against our supported runtimes.

Sequencing.

1. Spike (3–5 days): read source, review the 2.6.0 diff, answer the key questions, and produce a written go/no-go.
2. Benchmark: compare filter semantics against spatie/laravel-query-builder. If the delta is cosmetic, stop — this remains the likely and cheapest outcome.
3. Extract: only if step 2 shows real differentiation. Isolate grammar and remove framework coupling.
4. Adapt: Eloquent criteria adapter with a mandatory allowlist enforced in our layer regardless of upstream behaviour.
5. Harden: security review of parameter handling and load tests on endpoints with permissive filters.
6. Ship behind a feature flag with a documented rollback to hand-rolled scopes.

Operational Impact

Maintenance. 2.6.0 is a positive signal that the maintainer is active, but it does not change the ownership model. Zero dependents and a single maintainer mean we would still be adopting a fork, not a supported dependency. Budget ongoing ownership for security patching, PHP/Laravel version bumps, and bug triage with no upstream backstop. That remains the largest cost line and should drive the go/no-go more than code quality.

Support. Self-support only. Expect source and a README as the primary documentation. No vendor, SLA, or meaningful community escalation path.

Scaling. Application-tier cost remains negligible. The scaling risk is query cost: permissive filters become expensive predicates, and complex ordering over large tables can produce filesorts that only appear under production data volumes. The allowlist and pagination caps are the real controls, and they belong to us.

Failure modes.

• Unbounded or malformed filter parameters causing full-table scans under production data volume.
• User-supplied sort/filter fields reaching the query builder unvalidated — silent wrong results at best, injection at worst.
• Deeply nested filter expressions causing N+1 loads if the adapter triggers lazy relations.
• Upstream abandonment leaving the fork to drift from PHP/Laravel baseline support.
• Behavioural drift between fork and upstream, making future re-sync a rewrite rather than a merge.
• Mistaking 2.6.0’s sandbox and DI maintenance for production hardening — it is not.

Ramp-up. The codebase is small and the domain is well understood, so a mid-level engineer can be productive in days. The real onboarding cost is reverse-engineering the grammar from source, since documentation is thin. Recommend a single owner and a written internal spec of the filter grammar so the fork does not become tribal knowledge.