Elasticquent Laravel Package

Product Decisions This Supports

• Build vs. buy for search. Elasticquent is a thin mapping layer, not a search platform. It lets you answer "can we get keyword search into the product without owning a search service?" — the answer is "partially." It removes boilerplate (index management, model-to-type mapping, bulk indexing hooks, query helpers like complexSearch and aggregate) but leaves relevance tuning, analyzers, index lifecycle, and reindex/backfill orchestration entirely with your team. Use it to scope the real build cost rather than to conclude search is cheap.
• Roadmap sequencing for search features. Because the package couples Eloquent models directly to index writes via a trait (addToIndex, removeFromIndex, addAllToIndex), it shapes when search can ship. Model-level indexing is fast to demo but makes denormalized/search-shaped documents awkward. That pushes a real decision: ship search-as-mirror-of-tables now, or invest in a projection/event pipeline first. This package biases you toward the former — a defensible v1 if search is a "find my record" feature, not a "discover relevant content" feature.
• Feature scope decisions. Mapping Eloquent types 1:1 to Elasticsearch types is fine for single-entity lookup and admin-style filtering. It is a poor fit for cross-entity search, faceted catalogs, or anything needing custom analyzers, synonyms, or per-field boosting. That constraint is a useful forcing function for cutting scope in v1 and deferring the "unified search bar" to a later phase.
• Platform/infra decisions. Adopting it means accepting an Elasticsearch cluster as a supported dependency — ops ownership, cost, backup/restore, and version upgrade cadence all become product concerns, not just engineering ones. Worth pricing explicitly before committing.
• Risk and maintenance decisions. With 0 stars and 0 dependents, this fork has no community, no visible security response, and no adoption evidence. That is a vendor-risk input to the build/buy decision: you should assume your team owns the code. Budget for a fork-it-internally line item, or treat it as a reference implementation to copy patterns from rather than a dependency to install.
• Technical-debt / migration decisions. The package's core abstraction is Elasticsearch types, a concept removed in ES 7 and absent in ES 8. If your platform standard is a modern ES cluster, this is a dead end and the decision becomes "extract the trait's ergonomics into our own thin wrapper" — a small, bounded piece of work that this package helps you estimate.

When to Consider This Package

Consider it when all of the following hold:

• You are on a Laravel/PHP stack and want to avoid writing boilerplate for index creation, mapping, and bulk model indexing.
• Search is a secondary capability — record lookup, admin filtering, simple keyword match — not the product's core value.
• Your Elasticsearch version still supports mapping types (i.e., pre-7, realistically 1.x–5.x era), or you are prepared to rework the type layer.
• You have an engineer who can read the source and own it; the code is small enough to vendor and patch.
• You are explicitly treating it as a starting point or reference, not a long-lived third-party dependency.

Look elsewhere — or build a thin internal wrapper — when:

• You are on Elasticsearch 7/8 or OpenSearch. Types are gone; the central abstraction is wrong, not merely outdated.
• You need relevance engineering: custom analyzers, synonyms, per-field boosting, vector/semantic search, or cross-index search.
• Search is a headline roadmap item with a dedicated owner. At that point the abstraction becomes a constraint, and the cost of migrating off it later exceeds the cost of writing the ~200 lines yourself.
• You need an actively maintained dependency with a security response process. Zero stars, zero dependents, and no upstream activity fail standard OSS intake checks; expect procurement/security review to flag it.
• You need async indexing, reindex-with-zero-downtime, or multi-model/denormalized documents — these require an event-driven pipeline the package does not provide.
• You are evaluating forks specifically: confirm what this fork changes versus upstream elasticquent/elasticquent. If the diff is trivial, the fork adds risk without benefit.

How to Pitch It (Stakeholders)

To executives: This is a small Laravel library that connects our models to Elasticsearch. It is a starter kit, not a search product — it saves our team roughly the boilerplate of wiring index creation and model indexing, but it does not give us relevance tuning, search quality, or the operational maturity a customer-facing search feature needs. The package itself is a low-signal, low-adoption fork (no community, no dependents), so we should assume we own the code either way. Recommendation: use it to size the search feature — copy the patterns, don't take the dependency — and treat Elasticsearch itself (cost, ops, versioning) as the real commitment in this decision.

To engineering: Useful as a pattern reference for a thin Eloquent-to-ES adapter. Do not adopt as a dependency: the model is Elasticsearch mapping types, which ES 7+ removed, and there is no maintenance signal. Read ElasticquentTrait for the ergonomics worth keeping (index naming, bulk indexing, query helpers), then implement a small internal wrapper against the current official PHP client. Estimate the extraction as a bounded task and flag it as the reusable asset from this evaluation.