- Does makinacorpus/autocomplete-bundle work with Laravel?
- No, not out of the box. It is a Symfony bundle built on Symfony's Form component, Twig form themes, bundle/DI registration, and (almost certainly) Doctrine ORM for its suggestion queries — none of which Laravel ships. Laravel shares symfony/http-foundation and some Symfony contracts, but that is not enough to boot this package. Treat it as foreign Symfony code to port, not a Composer dependency to install.
- Can I just composer require makinacorpus/autocomplete-bundle in a Laravel app?
- You can run the command, but you will not get a working autocomplete field. The package registers a Symfony bundle and exposes Symfony Form types; Laravel has no bundle registration step, no Form component, and no Twig environment to render the widget. Any adoption path forces you to pull in symfony/form, symfony/twig-bridge, Twig, and a Doctrine entity manager alongside Eloquent — two templating engines and two persistence layers in one application.
- What PHP and Symfony versions does this bundle require?
- The repository is effectively unmaintained (1 star, no dependents, no visible community), and bundles of this vintage typically predate PHP 8.x and Symfony 5/6/7. Expect the composer.json constraints to conflict with modern PHP and with the Symfony packages Laravel already pulls in. Diff its composer.json against your PHP and Laravel versions as a blocking gate before spending any spike time on it.
- What does the package actually provide?
- Three things: a reusable Symfony Form type for autocomplete fields, controller/endpoint plumbing that serves JSON suggestions, and a frontend AJAX widget (JS/CSS) that renders the typeahead UI. The Doctrine integration lets the server side query entities for matching values. In a Laravel context only the frontend widget is realistically reusable.
- How do I build an autocomplete field in Laravel without this package?
- A JSON route that returns suggestions, a Blade component or Alpine.js typeahead on the frontend, and a parameterized query (Eloquent LIKE, or Laravel Scout with Meilisearch/Typesense) behind it. Add auth scoping and rate limiting to the endpoint. This is a few hours of work and gives you code your team owns and can test — versus a multi-day porting project with no upstream support.
- Can I reuse just the JavaScript autocomplete widget?
- Yes, and that is the most realistic option. Vendor only the frontend assets into resources/js, then reimplement the server endpoint as a Laravel controller and route against your actual data model. Expect to salvage roughly 20 to 30 percent of the package this way, and review the JS before shipping it since it is unmaintained code.
- Can the autocomplete query Eloquent models instead of Doctrine entities?
- Not without rewriting the server side. The bundle's suggestion source is wired through Doctrine ORM entity lookups and Symfony's service container, neither of which maps onto Eloquent or Laravel's container. If your data lives in Eloquent models or an external API, you are writing the query layer yourself regardless — so start from a Laravel-native endpoint instead.
- Is there a security risk in adopting an unmaintained autocomplete upload widget?
- There is real risk. Autocomplete widgets that also handle file uploads touch two historically high-risk areas: unrestricted file upload with path traversal, and unbounded LIKE queries against user input. Missing CSRF protection and missing rate limits are common in older bundles. If you keep any server-side code, add Laravel's UploadedFile validation, filesystem disks, CSRF middleware, throttling, auth scoping, and parameterized queries yourself.
- What are the alternatives for autocomplete in Laravel?
- Use Laravel Scout with Meilisearch or Typesense for large datasets, Livewire or Alpine.js for the UI layer, and a plain JSON endpoint for small ones. Each is maintained, documented, and integrates with Eloquent and Laravel's auth out of the box. If you already run Scout or Meilisearch, this bundle adds nothing beyond a UI wrapper you can rebuild in an afternoon.
- Who maintains the code if we fork or port this bundle?
- You do. The package has no active maintainer to escalate to and no changelog discipline to plan upgrades against, so a fork becomes permanent internal ownership with no upstream fixes. Decide that ownership explicitly before any spike, and confirm the licensing terms in composer.json. Given a low opportunity score and no Symfony runtime in the estate, reimplementing in Laravel is usually the cheaper and safer call.