Ux Search Laravel Package

Technical Evaluation

Architecture fit. This is the first and most important finding: mezcalito/ux-search is a Symfony UX package, not a Laravel package. It is built around Symfony's bundle system, Twig rendering, Symfony UX Turbo/Live Components-style interactivity, and (in all likelihood) Doctrine ORM/DBAL for the faceted query layer. Laravel's equivalents — service providers vs. bundles, Blade vs. Twig, Eloquent vs. Doctrine — are not interchangeable. There is no Laravel service provider, no Blade component set, no Eloquent adapter, and 0 dependents on the registry, which means no community has yet proven a Laravel integration path. Treat "Laravel/PHP package" in the brief as a category mismatch, not a minor porting detail.

Integration feasibility. Low as-is. The three viable routes are: (1) Port the faceted-search logic into Laravel-native code — feasible only if the underlying query builder is thin and framework-agnostic, which needs source review; (2) Bridge — run the package inside a Symfony sidecar and expose it over HTTP/JSON to the Laravel app, which adds an operational component for a 66-star dependency; (3) Substitute — implement faceted search with Laravel Scout + Meilisearch/Typesense/Algolia, or Spatie's query builder for DB-level facets. Route 3 is almost certainly the correct default; routes 1 and 2 only make sense if the package's facet aggregation logic is genuinely differentiated.

Technical risk. High. Signals against: 66 stars is pre-traction; 0 dependents means zero production validation and no downstream bug reports to learn from; a single-maintainer org (Mezcalito) creates bus-factor risk; the release date of 2026-08-19 is anomalous and needs verification (either a metadata artifact or a pre-dated release that undermines trust in the registry's freshness signal). MIT license is clean and removes legal friction — that is the one unambiguously positive data point. Opportunity score of 16.83 against an overall score of ~19.8 suggests the scoring model sees a narrow or unproven niche rather than a growth area.

Key questions.

• Does the package contain any framework-agnostic core (query parsing, facet aggregation, filtering) that could be lifted out, or is it Twig/Doctrine-coupled end to end?
• What search backend does it assume — raw SQL LIKE, Doctrine's SQL filter API, Elasticsearch, Meilisearch, Algolia? This determines whether it is even relevant to our stack.
• Who maintains it, what is the release cadence, and are there open issues/PRs indicating abandonment?
• Does it ship tests, and are they run in CI? A faceted-search library without a test suite is not adoptable.
• Is the 2026-08-19 release date real, and does the repo show commits within the last 90 days?
• What is the actual bundle size and transitive dependency surface (Symfony version constraints, Doctrine version constraints)?

Integration Approach

Stack fit. Poor for a Laravel codebase. If the house stack is Symfony, fit improves substantially and the evaluation shifts to "promising but unproven." If the house stack is Laravel — as the brief states — the honest recommendation is to not integrate this package and instead design faceted search against a first-class Laravel option. Recommend confirming the stack before any further effort is spent.

Migration path. If, after source review, the facet logic proves portable: extract the facet aggregation and filter-parsing layer into a standalone PHP namespace, wrap it in a Laravel service provider, and reimplement the UI in Blade + Livewire. Budget this as a fork-and-own effort, not an integration — once forked, upstream becomes a reference rather than a dependency, and the 0-dependents risk becomes irrelevant because we carry the maintenance. That is a real cost and should be sized (roughly 2–4 weeks for a simple facet set, materially more for hierarchical/range facets with URL-state management).

Compatibility. Verify PHP version constraints and any Symfony version pins; Symfony packages frequently pin minor versions tightly, which will conflict with a Laravel app's Symfony components (Laravel itself depends on symfony/* transitively — HttpFoundation, Console, Finder, etc.). Version-constraint collisions here are a concrete, likely blocker even for the "lift the logic out" route. Check composer why-not early.

Sequencing. (1) Stack confirmation — Symfony or Laravel. (2) 1-day source audit of the repo: read composer.json, the bundle class, and the query layer; confirm backend assumptions and test coverage. (3) If Laravel: run a 2-day spike on the substitute path with Meilisearch + Scout, since that is where the team is likely to land anyway. (4) Only escalate to fork-and-own if the audit shows genuinely non-obvious facet logic worth preserving. Do not start with a proof-of-concept install — the framework mismatch will consume the spike without producing a decision.

Operational Impact

Maintenance. Fork-and-own implies we own the code permanently: security patches, PHP version bumps, backend driver updates. At 66 stars and 0 dependents, upstream is unlikely to absorb our patches and unlikely to survive as a maintained project over a multi-year horizon. If we instead depend on the package directly inside a Symfony context, we inherit single-maintainer risk with no fallback maintainer community.

Support. No commercial support, no evidence of a responsive maintainer, no downstream users to consult. Internal escalation path is "read the source," which is acceptable for a small utility and unacceptable for a component on the critical search path.

Scaling. Faceted search is a hot path — every filter interaction is a query, and facet counts are typically the expensive part (multiple GROUP BY aggregations per request). Whether this scales depends entirely on the backend assumption, which is currently unknown. If it issues per-facet COUNT queries against the primary database, it will not hold up under real filter traffic and will need caching or a dedicated search engine — at which point the package's value proposition largely evaporates, since the search engine provides faceting natively.

Failure modes. (a) Silent degradation — facet counts drifting from result sets due to caching or stale index; users see filters that yield zero results. (b) Query amplification — N facets × M filter combinations producing unbounded DB load under crawl or abusive filtering; needs rate limiting and query-count ceilings. (c) URL-state divergence — facet state encoded in query strings is a common source of shareable-link breakage and cache-poisoning if not canonicalized. (d) Abandonware — a PHP minor release breaks the package with no upstream fix; the mitigation is the fork, which must be planned for on day one, not discovered during an incident.

Ramp-up. Low for the substitute path (Scout + Meilisearch is well-trodden and the team likely has adjacent experience); moderate-to-high for fork-and-own, requiring someone to internalize both the package internals and the facet-domain model. There is no documentation-driven ramp-up here — the repo README at 66 stars will not cover edge cases, so knowledge transfer is source-reading only.

Recommendation. Do not adopt for a Laravel codebase. Commission a one-day source audit to confirm the framework coupling and backend assumption, then proceed with a Laravel-native faceted search design. Revisit only if the stack is Symfony and the audit shows a tested, backend-agnostic core.