Filter Manager Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy on the filtering layer. The package is a low-end benchmark for "what does a filter-definition registry cost us," not a recommendation. It gives the team a concrete artifact to compare against a thin in-house ProductFilter module and against a search platform (Meilisearch, Algolia, OpenSearch). The decision it informs is the cheapest credible option, not the chosen one.
• Scope of PLP / faceted filtering at launch. Reading its filter-set model forces the question PMs actually own: which attributes are filterable (category, brand, price band, size, color), whether filters are merchandiser-managed, and whether filter-value counts and SEO filter pages ship in v1.
• API contract shape for filtered listings. Its register-and-compose model is a useful straw man for GET /products?filter[...] — how filters are named, combined, and validated — and for deciding how "no results" and "too many filters" degrade in the UI.
• Admin and merchandising roadmap input. It raises the right data-model questions — who defines filters, are they per-category, can they be reordered or toggled — even though the package itself offers no admin surface and no config versioning.
• Platform-fitness triage, not roadmap gating. Zero stars, zero dependents, and no release cadence mean no roadmap item should depend on upstream changes. Its only durable value is the design conversation it triggers.

When to Consider This Package

Consider it only as:

• A design reference. A time-boxed read of the source to extract the filter-definition and filter-set model, adapted into our own code. This is the realistic use.
• A consistency play inside an existing smoked/* Symfony estate, where matching an established internal family outweighs any ecosystem signal.
• A throwaway prototype with a handful of static filters and no production commitment.

Look elsewhere — decisively — when:

• The stack is Laravel. Despite the brief, this is a Symfony bundle, not a Laravel package: it will not auto-discover, will not register through Laravel's container, and integration means porting the classes, not installing the package. Use spatie/laravel-query-builder with Eloquent scopes, or Scout plus a search backend.
• Community validation, security response, or vendor assurance is required. Zero adoption means no triage process, no CVE monitoring, no upgrade path, and no one to escalate to — a failing under any procurement or risk review.
• Filtering must scale, or produce facet counts. Aggregations, relevance, synonyms, and typo tolerance belong in a search engine; a small filter manager will not get us there, and early savings do not offset the rewrite.
• The catalog is large, multi-locale, or merchandiser-operated. That needs an admin surface and config versioning the package does not provide.
• A dependency policy applies. An unmaintained package with no release cadence is a standing liability for the next framework major and a likely SCA-tool flag.

How to Pitch It (Stakeholders)

For executives: Not a platform investment. It is a small, zero-adoption, unmaintained Symfony helper for product-list filters — do not put it in a production dependency list. Its value is as a free reference for scoping filtering: roughly a day of engineering to evaluate, with the return in sharper design decisions rather than shipped code.

For engineering leads: Treat it as documentation, and note the taxonomy mismatch — it is a Symfony bundle, so on Laravel the honest framing is "port a few hundred lines," not "install a package." MIT-licensed, no community, no dependents, no upgrade guarantee. Recommended action: a time-boxed read-through to extract the filter-definition model, then build an internal filter module behind an interface so the backing engine (SQL scopes today, Meilisearch later) is a swap rather than a rewrite. Don't add it to composer.json; if anyone has vendored it, flag it in the dependency inventory as unmaintained. The real deliverable of the evaluation is a short internal note on the filter-registration model and known gaps against our catalog — that outlives the decision itself.

For the product team: This does not change the roadmap. It sharpens three questions we should answer before committing to filtering scope: which attributes are filterable and who owns that list, whether we need filter-value counts and SEO filter pages at launch, and what a "no results" state does to conversion. Those answers — not this package — determine the build.