Typeaheadbundle Laravel Package

Product Decisions This Supports

• Feature scoping for searchable form inputs. The capability at stake — typeahead/autocomplete on entity-backed selects (users, accounts, categories, tags) — is table-stakes UX for admin and back-office tooling. The decision this informs is which autocomplete primitive we standardize on, not whether we need autocomplete.
• Build vs. buy. This is a thin glue bundle: a Symfony form type plus Twig/JS wiring around Twitter Typeahead. Realistically ~50–150 lines of code you control. At 0 stars, 0 dependents, and a score of 0, it should be evaluated as a reference implementation to copy, not a dependency to adopt.
• Roadmap risk framing. Adopting it imports an end-of-life front-end library (Twitter Typeahead → typeahead.js, unmaintained since ~2015) into the product's long-term dependency graph for a non-differentiating feature. That is a poor risk-to-value trade.
• Use cases it maps to: internal CRUD forms with >500 options, "assign to user/owner" pickers, tagging fields, and any place where a native <select> becomes unusable. It does not cover multi-select tokenization, async pagination at scale, or accessibility-grade combobox behavior.
• Platform mismatch as a decision input. Despite the framing, this is a Symfony bundle, not a Laravel package — no service provider, no publishable config. If the stack is Laravel, the decision is "pick a JS library and wire it in Blade/Livewire ourselves," and this package is irrelevant except as a pattern reference.

When to Consider This Package

Consider it only when:

• You are already on Symfony, already vendoring Twitter Typeahead elsewhere, and need a throwaway internal prototype where the form-type wrapper saves an hour.
• The field is a simple single-select over a modest list with one backend endpoint, and no accessibility or mobile requirements are in scope.
• You are reading it for the integration pattern (form type → JSON endpoint → JS init), not requiring it in composer.json.

Look elsewhere when:

• You are on Laravel. Nothing here is reusable; use a maintained JS library directly.
• You need accessibility. Typeahead's ARIA/combobox behavior is dated; WCAG 2.1 AA combobox support is table-stakes for customer-facing surfaces.
• You need scale. No virtualization, weak async/pagination story; bloodhound has known rough edges.
• You need maintenance assurances. No visible tests, CI, release cadence, license review, or security posture. Zero dependents means zero community pressure to patch anything.
• You need multi-select, tokenization, or mobile-first behavior — Tom Select, Choices.js, or Algolia Autocomplete cover these and are maintained. On Symfony specifically, Symfony UX Autocomplete keeps the behavior in-framework; on Laravel, a small Stimulus/Alpine controller over a maintained library is the low-cost path.

Recommended default: do not add as a dependency. Budget 1–2 developer days to build the equivalent on a maintained library, and standardize it once across all forms.

How to Pitch It (Stakeholders)

For executives (one paragraph): We evaluated a small open-source add-on that puts an autocomplete dropdown on form fields in our admin tooling. It wraps a front-end library that has been unmaintained for roughly a decade and shows no adoption signals — no stars, no downstream users, no visible tests. The user-facing benefit is real but generic: fewer data-entry errors and faster form completion. Our recommendation is not to adopt it as a dependency, and instead spend one to two developer days building the same behavior on a maintained library. That gives us the UX, avoids inheriting an abandoned component for a non-differentiating feature, and keeps accessibility and mobile support on the roadmap rather than blocked by it. Cost is trivial; the risk we're avoiding is a long-tail dependency we'd have to fork and own.

For engineering (summary): Heads-up on a platform mismatch — this is a Symfony bundle (form type + Twig/JS wrapper), not a Laravel package, so nothing is directly installable on our stack. Underlying JS is Twitter Typeahead, superseded by typeahead.js and effectively EOL; Bloodhound has known issues and there's no ES-module support. No CI, tests, or release cadence, and zero dependents means no upstream pressure to fix anything. Proposal: treat the repo as a design reference only, and implement a thin Stimulus/Alpine controller plus a JSON endpoint. Standardize on Tom Select (or Symfony UX Autocomplete if we're in a Symfony service), which gives us ARIA-compliant combobox behavior, async loading, multi-select, and active maintenance. Decision needed: approve standardizing one autocomplete library across all forms. Estimate: 1–2 days; risk: low; reversibility: high.