- How do I install addons/elasticsearch in a Laravel app?
- Install it with Composer (composer require addons/elasticsearch), then publish any config the package ships and point your Scout engine configuration at it. Because the addons/ namespace suggests it was extracted from an application monorepo, confirm it is actually published on Packagist with tagged releases before you commit; you may need a VCS or path repository entry in composer.json. Run the install against the exact Laravel, Scout and elasticsearch-php versions you plan to ship with.
- Which Laravel and Elasticsearch versions does this package support?
- Per its description the package targets the official Elasticsearch 5.x-6.x client on Laravel 5, so treat it as a legacy-stack bridge first. The composer constraints are the source of truth: check that they allow your Elasticsearch server major and your elasticsearch-php client major before doing anything else. Mixing Laravel 9, 10 or 11 with elasticsearch-php 7 versus 8 is a known compatibility triangle, and the 8.x client changed namespaces, defaults and error handling, so a modern stack needs a proven spike rather than an assumption.
- Is addons/elasticsearch a Scout engine driver or just helper classes?
- The overview describes a thin adapter that converts Elasticsearch hits into Laravel-native LengthAwarePaginator and Collection objects, plus a logging helper. That is not the same as shipping a full Laravel Scout Engine implementation, and you should read the source to see whether one is included. If it is not, you still need a Scout driver underneath and this package only handles the result-shaping seam.
- How is addons/elasticsearch different from babenkoivan/scout-elasticsearch-driver?
- Verify this first: the package may be a fork of, or derivative from, babenkoivan/scout-elasticsearch-driver, so check which upstream commit it was based on and how far behind it is. The babenkoivan driver is the better-known option and typically bundles index, mapping and engine management, whereas addons/elasticsearch appears to focus on pagination, collection hydration and logging ergonomics. If you need index and alias lifecycle management out of the box, compare feature lists line by line before choosing.
- How do I paginate Elasticsearch results with Laravel's ->links()?
- Results come back as a LengthAwarePaginator, so ->links(), Blade foreach loops, API Resources and Collection methods work without special-casing, which is the main reason to adopt a helper layer at all. The ceiling to know about is Elasticsearch's index.max_result_window: a paginator built on from and size cannot page past 10,000 hits by default. Deep paging needs search_after, point-in-time or scroll, and the package description does not claim those, so test page depth behaviour before you rely on it.
- Can I use aggregations, function scores or raw query DSL with this package?
- This is a helper layer, not a query DSL surface, so expect aggregations, function scores, multi-index queries and other advanced constructs to require dropping down to the elasticsearch-php client directly. If product wants to control relevance tuning or run analytics-style aggregation workloads, a thin paginator bridge is the wrong abstraction. Keep an escape hatch to the raw client, or wrap the package behind your own SearchService interface.
- How do I test an Elasticsearch integration without hitting production?
- Mocking Elasticsearch rarely proves anything useful because the failure modes live in mappings, analyzers and query semantics, so run a real Elasticsearch instance in CI with a pinned image and pinned client versions. A half-day spike de-risks most unknowns: install the package, import one model, request page 2, and assert you get a LengthAwarePaginator with the correct total and a collection of Eloquent models that can eager-load relations. Keep that as a smoke test in your version matrix.
- Does it support deep pagination beyond 10,000 results?
- A paginator helper does not solve Elasticsearch's 10,000-hit from plus size window, and the package description makes no claim about search_after, point-in-time or scroll support. Establish what happens at the window boundary: whether results are clamped, an exception is thrown, or results silently go wrong. If your catalogue is large and users page deep, plan for search_after at the application level or restrict how far users can page.
- Is addons/elasticsearch actively maintained and safe for production?
- Treat it as an early-adopter dependency: low star count, no visible dependents and a single maintainer mean a low bus factor and no crowd-sourced fix path. The MIT license and small surface area keep the exit cheap, but pin exact versions, check maintainer issue-response time over the last 12 months, and keep your own integration tests. Wrap it behind an interface so replacing it later is a one-class change.
- How do I migrate to this package from Scout's database driver or Algolia?
- From Scout's database driver it is the lowest-risk switch: define toSearchableArray(), set the engine config, backfill with scout:import, then run dual-read comparisons before flipping traffic. From Algolia or Meilisearch the Scout surface is mostly normalized, so the real work is mapping and analyzer design rather than code. From a hand-rolled Elasticsearch integration it is the highest risk, because you must inventory every existing query shape first and the helper layer may not express all of them.