Ux Search Laravel Package

Product Decisions This Supports

• Build vs. buy for faceted search UI. This package targets the "last mile" of search — the Twig/Stimulus/Live Component layer that renders result lists, filter checkboxes, ranges, and active-filter chips. That's typically 2–4 sprints of front-end + backend glue for a team. Adopting it lets you spend that budget on relevance tuning and data quality instead of plumbing.
• Framework fit decision (critical flag). Despite the brief describing this as a Laravel/PHP package, mezcalito/ux-search is a Symfony UX package. It will not drop into a Laravel app. The real decision it informs is: for our Symfony services, do we standardize on this for search UI, or hand-roll a Blade/Livewire equivalent for Laravel services? Treat it as a Symfony-only candidate and keep the Laravel search story on a separate track.
• MVP and roadmap sequencing. Faceted search is usually a "phase 2" capability behind a basic query box. This package makes phase 2 cheap enough to pull forward — useful when deciding whether filtering ships in the current quarter or the next.
• Scope of the search backend. A UX-layer package implies you can start with Doctrine/DB-backed filtering and defer a real search engine (Elasticsearch, Meilisearch, Algolia, Typesense). That's a meaningful infra-cost and ops-burden deferral, and a defensible "don't buy search infra yet" recommendation while catalog size is modest.
• Internal tools and admin back-offices. The highest-confidence use case given the maturity profile: low-traffic, authenticated, internal search surfaces where a bug is an inconvenience rather than a revenue event.
• Prototype and discovery work. Cheap way to put a credible faceted-search demo in front of stakeholders to validate filter taxonomy and user expectations before committing to a search vendor contract.
• Vendor-contract timing. The project's continued (if small) release cadence is now part of the "wait vs. buy search infra" calculus: a hardening-focused 0.7.0 suggests the maintainer is investing in correctness rather than features, which slightly strengthens the case for deferring a paid search platform for another quarter.

When to Consider This Package

Consider it when:

• The application is Symfony 6/7 with Doctrine ORM entities as the searchable data source, and the team already uses Symfony UX / Live Components or is willing to.
• Catalog size is modest (roughly tens of thousands of records or fewer) and filtering can be expressed as SQL predicates — no need for relevance scoring, fuzzy matching, synonyms, or typo tolerance.
• You want server-rendered, progressively-enhanced search without adding a JS SPA or a search cluster.
• The surface is internal, low-traffic, or an early-stage MVP where time-to-market dominates reliability requirements.
• You have PHP capacity to own a fork. With 66 stars and 0 dependents, assume you may be the only team hitting an edge case.
• You are willing to track a pre-1.0 release line: 0.7.0 is a hardening/quality release (PR #52) with no announced features or deprecations, so minor bumps can still carry behavioral changes. Pin versions and read the diff before upgrading.

Look elsewhere when:

• The stack is Laravel, Rails, Django, or a JS frontend — this is not portable, and the maintenance burden of adapting it exceeds writing it.
• You need search relevance as a product differentiator: ranking tuning, boosting, synonyms, multilingual analysis, semantic/vector search. That's an engine decision (Meilisearch for cost/simplicity, Elasticsearch/OpenSearch for scale and control, Algolia/Typesense for managed speed).
• Scale, latency SLOs, or faceted counts over large datasets matter — DB-backed facet counting degrades; you'll want a search index.
• Procurement or compliance requires vendor support, SLAs, security review evidence, or a maintained-release cadence with a public track record. (Note: 0.7.0 is a positive cadence signal, but a single hardening PR is not yet a track record.)
• Zero-dependency-count is a hard policy — 0 dependents means no ecosystem signal; there is no swarm of teams who have already found the bugs for you.

Diligence checklist before adoption: confirm compatibility with your exact Symfony and Doctrine versions, inspect the test suite and CI, verify the Live Component behavior under concurrent filter changes, check how facet counts are computed (N+1 query risk), and identify a named internal owner with a fork-and-patch plan.

0.7.0 review note: the release is a single "fix/hardening and quality" change set (PR #52) with no stated new features, breaking changes, or deprecations. It does not change the adoption recommendation. It does two things: (1) it is mild evidence of an actively maintained project rather than an abandoned one, which softens — but does not remove — the single-maintainer risk; and (2) it is worth reading the actual PR diff during the spike, because "hardening" in a 0.x package is exactly where silent behavior changes tend to hide, particularly around filter state and query construction. Confirm whether any of the hardening touches facet-count query generation, since that was the top technical risk identified.

How to Pitch It (Stakeholders)

For executives (one paragraph): Faceted search — the filter sidebar and result grid users expect on any catalog — is expensive to build and easy to get wrong. mezcalito/ux-search is an MIT-licensed open-source component that provides that layer for our Symfony applications, letting us ship filtering in weeks rather than quarters and defer a paid search platform until we have evidence we need one. The trade-off is maturity: it's a small, single-maintainer project with negligible adoption, though it is still being actively maintained (a hardening release shipped as 0.7.0). We therefore recommend a time-boxed spike on one low-risk surface rather than a platform-wide commitment. Cost is zero in license fees; the real investment is a few days of engineering evaluation and a named owner.

For engineering leadership: It's a Symfony UX package — Twig components plus Live Components/Stimulus for the interactive filter behavior — sitting on top of Doctrine. That means no new infrastructure, no new language, no JS build changes beyond what Symfony UX already requires. It fits our existing deployment and on-call model. Risks to price in: tiny community (66 stars, 0 dependents), so treat upstream as a starting point, not a dependency we can wait on; potential query-count blowups from facet aggregation; version-coupling to Symfony UX, which moves fast; and a pre-1.0 version line where minor releases can change behavior. The recent 0.7.0 is a hardening rather than a feature release, which is directionally reassuring, but it's one PR — not a stability guarantee. Mitigation: vendor a pinned copy or fork, review the 0.7.0 diff for filter/query behavior changes, write integration tests around our filter taxonomy, and set an explicit review date to re-evaluate against Meilisearch or a hand-rolled implementation.

Ask: approve a 3–5 day spike on one internal, non-revenue-critical search surface, pinning to the current release; go/no-go based on query performance against realistic data volume, a maintainability read of the codebase (including the 0.7.0 hardening diff), and upstream responsiveness to an issue or PR.