Filter Manager Bundle Laravel Package

Technical Evaluation

Architecture fit. The brief labels this a "Laravel/PHP package," but the artifact is a Symfony bundle (FilterManagerBundle, bundle bootstrapping, Symfony DI extension conventions). That distinction is the single most important thing a TPM should surface, because it determines whether the effort is an install or an adaptation. In a Laravel codebase there is no bundle registration hook, no auto-discovery, no service wiring into Laravel's container — the realistic path is to read the filter-definition model and re-implement it as an internal module (or as Eloquent scopes behind spatie/laravel-query-builder). What does fit the Laravel stack conceptually is the core abstraction: a central registry of named filter definitions plus composable filter sets, applied at the request boundary rather than scattered through controllers. That is exactly the shape a ProductFilterResolver/FilterSet seam should take, and it is worth copying regardless of the engine underneath (SQL scopes today, Scout/Meilisearch later).

Integration feasibility. Low as a dependency, moderate as a reference. Zero stars, zero dependents, score zero means there is no downstream evidence to learn from: no issue history for known breakages, no usage patterns for multi-select attributes, price bands, stock/visibility predicates, variant-vs-product granularity, or facet counts. MIT removes legal friction but not the read-the-source tax. For a TPM, the honest framing is: the evaluation cost is bounded (roughly a day of engineering), and the value is a straw-man data model and a GET /products?filter[...] contract, not working code in the repo.

Technical risk. The dominant risk is provenance, not code: a single-maintainer, zero-adoption component sitting directly in the query-construction path of a revenue page. Second is query safety — a filter manager by definition converts user-supplied parameters into predicates, and with no visible test suite you cannot assume it allowlists column and sort names rather than interpolating them into DQL/SQL. Third is version rot (no releases, no CI signal, unknown PHP/Symfony constraints, possibly pre-Symfony-6 APIs). Fourth is abstraction mismatch: if it emits a Doctrine QueryBuilder mutation rather than a filter value object, extracting it into Laravel is a rewrite, not a port.

Key questions. (1) What are the composer.json PHP and symfony/* constraints, and is there a last-commit date that indicates dormancy? (2) Does it produce a filter value object (portable, adaptable) or a query-builder mutation (opinionated, hard to swap)? (3) How are filters registered — attributes, YAML/config, or hardcoded — and is that model per-category extensible? (4) Are filter fields and sort keys validated against an allowlist? (5) Is there any facet/aggregation or count support, or only boolean predicates? (6) Does the abstraction survive our catalog: multi-select, ranges, variant-level attributes, visibility/stock? (7) Who owns the filterable-attribute list in our product org — merchandising, catalog ops, or engineering? (8) Is the domain match close enough that adaptation beats a from-scratch layer of a few hundred lines?

Integration Approach

Stack fit. Worst case, and the stated one, is Laravel: vendor the filter classes into app/Support/Filtering, discard Symfony plumbing, and expose them behind a single ProductFilterResolver interface. Best case is a Symfony + Doctrine catalog with faceting — the package's native habitat — and even there, evaluate against spatie/laravel-query-builder equivalents if the org is Laravel-heavy and consistency matters more than reuse. Partial-fit hybrids (Symfony + Eloquent, Laravel + Doctrine) cost more than they save and should be avoided.

Migration path. There is no floating constraint to take on an unversioned package. If any code is adopted: fork to a private repo or vendor into the monorepo, pin to a commit SHA, preserve upstream history so revival remains mergeable, and wrap it behind our own interface so the package is one implementation of resolve(RequestCriteria): FilterSet. That seam is what makes this a reversible experiment instead of a rewrite, and it is also the cleanest place to hang a characterization test suite that pins observable behavior.

Compatibility. Verify the real matrix before any commitment: PHP version, Symfony major, doctrine/orm/doctrine/dbal, and whether the bundle still relies on APIs removed in Symfony 6/7. A PHPStan pass at a low level plus a throwaway Composer install in a scratch branch surfaces most of this in an hour. For the Laravel path, "compatibility" is really "how much of the source is framework-coupled" — measure that by counting files that reference Symfony namespaces.

Sequencing. (1) One-day spike: read the source, stand up a toy schema with 3–4 filters, extract the filter-definition model. (2) Decision gate — if the model maps cleanly onto our catalog, fork and pin; if not, stop and take the build path. (3) Adopt only behind the adapter interface, with characterization tests and a feature flag. (4) Remove the flag, then record the outcome in the dependency inventory. The TPM job here is enforcing the timebox: the failure mode is "evaluate a package" metastasizing into multi-sprint archaeology for something with zero dependents. Default posture is build, not adopt, unless the spike shows a near-exact domain match and the source is small enough to own outright.

Operational Impact

Maintenance. Assume unmaintained and budget accordingly. Adoption transfers the full burden — framework upgrades, security patches, bug fixes — to us, permanently. Treat any fork as first-class internal code with a named owner and a calendar reminder against the next framework major, or it silently rots into an upgrade blocker. For a filter layer, the honest comparison is "one sprint saved now" against "an internal fork we own forever," and the fork usually loses.

Support. Effectively none: no issue triage, no CVE monitoring, no upgrade guides, no community to search. The entire support surface is our own documentation plus characterization tests, which makes the spike engineer's written notes a hard deliverable, not a nice-to-have. That is a concentrated bus-factor risk on a one-person integration and should be named in the risk register.

Scaling. The filter manager itself is request-scoped and cheap; the risk is in what it emits. Watch for N+1s when filters traverse variants or attribute values, unindexed predicates on high-cardinality columns, and COUNT-heavy facet queries on large catalogs. Because the package likely owns query construction, index tuning and aggregation work will force a fork anyway — which erodes the "just install it" value proposition decisively once facets-with-counts appear on the roadmap.

Failure modes. Ranked by likelihood × blast radius: (a) silent filter degradation — a filter stops applying after a schema change and quietly returns unfiltered results, a correctness bug users won't report; (b) predicate injection if user-supplied field or sort names reach the query unvalidated; (c) dependency hell from pinned transitive versions blocking unrelated Laravel/Symfony upgrades; (d) SCA scanner block — an unmaintained, zero-adoption dependency is a likely compliance flag, creating process friction for a component worth perhaps a sprint; (e) bus-factor collapse if the sole integrator leaves. Mitigations are cheap and mostly non-technical: allowlist validation, characterization tests, an inventory entry, and a documented owner.

Ramp-up. Intrinsic learning cost is low — the domain surface is small and the abstractions conventional. Effective ramp-up is dominated by reverse-engineering undocumented behavior rather than following a designed API, so allocate source-reading time, not tutorial time. The durable deliverable of this evaluation is a short internal note covering three things: the filter registration model, the query-construction contract, and the known gaps against our catalog schema. That note, plus the build-vs-adopt recommendation and the product questions it sharpens — which attributes are filterable and who owns them, whether facet counts and SEO filter pages ship at launch, and what "no results" does to conversion — is worth more than the package itself.