Livewire Searchable Select Laravel Package

Product Decisions This Supports

Feature decisions this package informs:

• Build vs. buy for searchable select inputs. Any roadmap item requiring a typeahead/autocomplete dropdown over a server-driven option list in a Livewire app (e.g., assigning a user to a project, picking a customer, tagging records) is a candidate for reuse rather than a bespoke component. The v2.0.1 fixes target exactly the interaction details teams burn sprint time on: keeping the search term in sync between Alpine state and the Livewire component, preserving a selected value when the user re-clicks the input, and auto-closing the dropdown after selection.
• Scope/effort estimation for form-heavy epics. A maintained component with published install (composer require fabioguin/livewire-searchable-select:^2.0.1) removes a classic multi-day "make the select feel good" task from estimates. Use it as a planning reference point when sizing admin/settings/CRUD surfaces where searchable selects appear 5–20 times.
• Deferring a custom design-system investment. If the design system has no first-class searchable-select primitive yet, this package can unblock delivery of dependent features now, with a documented exit path later. The trade-off is styling and accessibility conformance risk — decide deliberately, not by default.
• Maintenance-health signal for the dependency portfolio. A patch release fixing Alpine/Livewire state-sync and UX bugs (rather than sitting idle) is evidence of an actively maintained dependency. That supports keeping it in the portfolio and is relevant input to any "dependency risk" register the PM owns.

Roadmap-level decisions:

• Where this lands on the roadmap: treat as an enabler, not a headline feature. It should not consume roadmap narrative space, but it does unblock form-heavy epics in admin tooling and internal workflows.
• Version/upgrade planning: v2.0.1 is a patch release — bug fixes and internal technical changes (using $wire.searchTerm directly in the x-model binding, respecting isSelected state on click, automatic dropdown closure). No breaking changes, no deprecations, no new capabilities. The major-version marker (^2.0.1) does imply a v1→v2 migration exists; if the codebase is still on v1, that migration is a separate, unrelated piece of work and should be scoped by engineering, not inferred from these notes.
• Not a decision this supports: anything about scalability, server-side search performance, accessibility compliance, or test coverage. The release notes say nothing about those, so they remain open evaluation questions.

When to Consider This Package

Adopt when:

• The stack is Laravel + Livewire + Alpine.js and the frontend is already Alpine-based. The technical changes in v2.0.1 (x-model bound to $wire.searchTerm) confirm the component is tightly coupled to Livewire's reactive property model — it is not framework-agnostic.
• You need a server-driven option list with client-side search over the loaded set, and the interaction pattern matches what the component provides: type to filter, select, dropdown closes and state resets.
• You want a short path to shipping a form-heavy internal tool, admin panel, or settings surface where "good enough and consistent" beats "pixel-perfect and bespoke."
• You can accept the upgrade cadence and API surface of a single-maintainer package at the 2.x line, and someone on the team is willing to own version pinning and review changelogs on upgrade.
• The component's existing behavior is close enough to your design spec that customization is theming, not forking.

Look elsewhere when:

• You need large or remote datasets. The Alpine/Livewire searchTerm sync implies the search term is a Livewire property; if the option list is thousands of records, confirm whether the package supports server-side filtering before committing — the release notes don't establish this. If it doesn't, a dedicated combobox with async search is the better fit.
• Accessibility conformance is a hard requirement (WCAG 2.1 AA with keyboard navigation, ARIA combobox semantics, screen-reader announcements). Nothing in these notes evidences accessibility work — the v2.0.1 changes are about click behavior and model binding. Verify with your own audit; a custom accessible primitive or a mature headless UI library may be the safer path.
• You're not on Livewire, or you're on a Livewire version outside the package's supported range. The Alpine.js integration is the core of the component; there is no framework-neutral fallback.
• Vendor risk tolerance is low. No data yet on download volume, release cadence beyond this patch, or maintainer bus factor. If the component would sit on a critical revenue path, prefer an internally owned primitive.
• You need a design-system-owned component with a stable public API you control. A package you can't fork-and-own becomes a permanent upgrade obligation.

Practical evaluation gates before adoption (not answerable from release notes alone): check the repo's test suite and CI status, open-issue response time, latest commit date, Livewire version constraint in composer.json, and whether the styling is overridable without patching vendor code. Do a one-day spike against your actual Laravel/Livewire versions.

Upgrade guidance for existing adopters: v2.0.1 is a safe patch upgrade — no breaking changes or deprecations. The behavioral changes are user-visible improvements (dropdown now closes and resets after selection; clicking an input with an active selection no longer clears the search term). Any tests asserting the old dropdown-stays-open or search-term-resets-on-click behavior will need updating; flag that to QA as expected churn, not a regression.

How to Pitch It (Stakeholders)

For executives — the 30-second version: "Every form that asks someone to pick a person, customer, or record from a long list needs a searchable dropdown. We've found a small, actively maintained open-source component that gives us this in an afternoon instead of a sprint, at zero license cost. The latest release is a bug-fix patch that makes the dropdown behave the way users expect — it closes after you pick something and doesn't wipe your search when you click back in. There's no migration work and no cost. The trade-offs are that it's maintained by a single author and it doesn't yet have documented accessibility certification, so we'd use it on internal and admin surfaces first and audit before it goes anywhere customer-facing."

For engineering: "This is Livewire + Alpine — a drop-in composer require fabioguin/livewire-searchable-select:^2.0.1. v2.0.1 is patch-only: no breaking changes, no deprecations, no new API. Internally it now binds x-model directly to $wire.searchTerm, respects isSelected on click so an active selection isn't cleared, and closes/resets the dropdown after selection. Saves us building and then maintaining a stateful combobox. What I need from you before sign-off: confirm the Livewire version constraint matches ours, confirm the styling is overridable without patching vendor code, tell me whether searchTerm filtering is client-side only (that determines our ceiling on list size), and tell me your read on the test suite and issue activity. Also: if we're still on the 1.x line, scope the v2 migration separately — that's not covered by this patch."

For design/QA: "Two intentional behavior changes to test against rather than file as bugs: the dropdown now auto-closes after a selection and resets its state, and clicking into the input while a value is selected no longer clears the search term. Worth a pass on keyboard flow and screen-reader behavior since that's our open question with this component."