Filter Bundle Laravel Package

Technical Evaluation

Architecture fit. The first finding is a category mismatch: gns/filter-bundle is a Symfony bundle, not a Laravel package. It registers through Symfony's Kernel, DependencyInjection/*Extension, and a Configuration tree — none of which Laravel's service container consumes. Laravel borrows individual Symfony components, but it does not run the bundle lifecycle. Beyond packaging, the filtering model almost certainly targets Doctrine ORM query builders rather than Eloquent. Unless the filter primitives are framework-agnostic (an unverified assumption), adopting this into a Laravel codebase means forking it, not requiring it.

Integration feasibility. Low as a direct dependency; plausible only as a source-mining exercise. The realistic paths are: (a) vendor/fork the repository and strip the Symfony/Doctrine coupling to build a Laravel adapter, or (b) read it for design inspiration and implement filtering natively. Both are engineering projects, not composer require steps. Given 1 star, 0 dependents, and a last release of 2020-02-08, there is no external evidence that anyone has successfully integrated this outside its original author's context.

Technical risk. High, concentrated in abandonment:

The composite score of 0.305 and opportunity of 0.38 are consistent with this read — low adoption signal, weak ecosystem pull.

Key questions to resolve before any code is written.

1. Is the filter core ORM-coupled, or does it accept an abstract query/collection interface? This single answer determines fork-vs-reimplement.
2. What are the declared php, symfony/*, and doctrine/orm constraints in composer.json, and does the code actually run on our target PHP version?
3. Is filtering configured declaratively (YAML/config tree) or via annotations/attributes? Config-driven designs port more cleanly to Laravel's array-based config.
4. What is the license, and does it permit a closed fork?
5. Does our product need a filtering DSL at all, or do we need a handful of query-parameter conventions that spatie/laravel-query-builder already solves?

Integration Approach

Stack fit. Poor out of the box. A Symfony bundle assumes a kernel boot sequence, a compiler pass pipeline, and a bundle config hierarchy that Laravel does not provide. Even in a Symfony shop, a 2020 bundle against a modern Symfony major version is a compatibility investigation. In a Laravel shop, the bundle packaging is dead weight — only the underlying filter logic has any transfer value.

Migration path. Recommend a two-week spike, then a build-vs-fork decision, not an adoption. Concretely:

• Fork path (only if Q1 resolves favorably): vendor the repo into a private namespace, delete all Symfony DI/config plumbing, retain only pure filter logic, and write a thin Laravel adapter that maps request parameters to an Eloquent query builder. Budget for the adapter being larger than the retained core.
• Reimplement path (default recommendation): define our own filter contract — allowlisted fields, operator set, type coercion, authorization per field — and implement against Eloquent directly. Reference this repo for naming and DSL ergonomics only. Compare seriously against spatie/laravel-query-builder, which is maintained, Laravel-native, and has real dependents.
• No-go path: do nothing if the requirement is fewer than ~10 filterable endpoints; hand-written scopes are cheaper than any abstraction.

Compatibility. Treat the 2020 release date as a hard gate. Verify the PHP constraint matrix, confirm whether symfony/* and doctrine/orm requirements resolve alongside our current framework version, and check for deprecated syntax (each(), dynamic properties, createMock signatures) that breaks on PHP 8. If the fork does not run cleanly on our target runtime, the fork path closes and reimplementation is the only option.

Sequencing.

1. Spike (1 week): read composer.json, map the public API surface, attempt a PHP-version install in a scratch container. Output: fork-vs-reimplement recommendation.
2. Contract definition (1 week): specify the filter DSL — supported operators, allowlisting, coercion rules, error behavior for unknown fields. This artifact is reusable regardless of path chosen.
3. Implement or adapt (2–3 weeks): build against Eloquent behind the contract.
4. Index and performance review: confirm each filterable field has a supporting index before exposing it.
5. Rollout behind a flag: enable per-endpoint, not globally.

Operational Impact

Maintenance. The dominant cost. Adopting this package transfers full maintenance ownership to us on day one — there is no upstream to patch, no release cadence to track, and no maintainer to escalate to. A fork must be actively owned, versioned internally, and re-reviewed at each PHP and Laravel major upgrade. Estimate ongoing cost as an internally-owned library, not a dependency. If we reimplement, we own it anyway but without the legacy Symfony/Doctrine surface to drag along.

Support. None externally. Internal ownership means the team that integrates it also becomes the escalation path for every filtering bug, performance complaint, and edge case. Document the DSL and the allowlist policy at integration time, not retroactively; undocumented filter semantics are a recurring source of "why did this query return nothing" support tickets.

Scaling. Compute cost is negligible — a filter bundle adds no meaningful runtime footprint. The scaling risk is query behavior: unbounded filter combinations invite full-table scans, deep OFFSET pagination, and pathological WHERE clauses from user-supplied parameters. Mitigations are ours to enforce: strict field allowlisting (never accept arbitrary column names), per-field operator restrictions, index validation before exposure, mandatory pagination caps, and query-time budget alerting on the filtered endpoints. None of this is provided by the package.

Failure modes to instrument for.

• Framework upgrade lock-in — the fork pins us to an unsupported baseline; detected only when a PHP or Laravel major upgrade stalls.
• Silent semantic drift — filter behavior differs subtly between endpoints as adapters are hand-written; caught by a shared conformance test suite over the DSL.
• Security regression in transitive dependencies — no upstream triage means scanner noise with no patch path; caught by dependency scanning plus a documented "accept risk / replace" decision record.
• Query performance cliff — a new filterable field ships without an index; caught by slow-query logging with an explicit threshold on filtered routes.
• Bus-factor — one or two engineers understand the adapted core; mitigated by the contract spec being the source of truth, not the code.

Ramp-up. The code volume is likely small, so reading it is cheap; the context is expensive. There is no documentation, no test suite of known quality, and the original author's design intent must be reverse-engineered. Realistically a mid-level engineer needs 3–5 days to be productive in a fork. A native reimplementation against our own contract has a steeper first week but a materially lower long-term comprehension cost, because the team wrote it against requirements they already understand.

TPM recommendation. Do not adopt as a dependency. Treat gns/filter-bundle as a reference implementation for a one-week spike, and default to either a native Eloquent layer or spatie/laravel-query-builder unless the spike proves the filter core is ORM-agnostic and we need its specific DSL semantics. The scores — 0.305 overall, 0.38 opportunity — understate the risk only slightly; the deciding factor is the framework mismatch, which is a structural problem rather than a quality one.