Ongr Elasticsearch Bundle Laravel Package

Product Decisions This Supports

• Search feature scoping. This bundle is the Symfony-side plumbing for Elasticsearch: index lifecycle, document-to-object mapping, repositories, and query building. If it were healthy, it would underwrite decisions like "ship faceted catalog search," "add relevance-ranked site search," or "build an internal log/event exploration tool" without hand-rolling that plumbing.
• Build vs. buy for the integration layer. Adopting it is a decision to buy the integration (not the search engine). The real question is whether a third-party abstraction over the official Elasticsearch PHP client is worth an extra dependency between your domain models and the wire protocol.
• Roadmap sequencing. Search features tend to be load-bearing later (autocomplete, synonyms, per-tenant indices, reindex-without-downtime). A bundle that owns your mapping model shapes how expensive those follow-ons become — worth deciding before search becomes a Q3 commitment rather than after.
• Stack fit — and this is the first decision it actually forces. The brief frames this as a Laravel/PHP package, but it is a Symfony bundle; it has no place in a Laravel application. If the product is Laravel, the live options are Laravel Scout with an Elasticsearch driver, or the official elasticsearch/elasticsearch client wrapped in your own service. That decision should be closed early so the team isn't evaluating candidates from the wrong ecosystem.
• Use cases this pattern serves, regardless of vendor: e-commerce catalog search, CMS/help-center content search, customer-support ticket search, observability consoles. The pattern is sound; this specific artifact is not the vehicle.

When to Consider This Package

Adoption criteria — in practice, all of these would have to be true:

• You maintain a legacy Symfony 2.x/3.x application already pinned to this bundle, and it is working today. Migrating off it is then a scheduled piece of work, not an emergency; the bundle's job is to keep the lights on until then.
• You are prepared to fork and own it: MIT license permits it, and a fork with an internal maintainer, CI, and an upgrade path is a legitimate option — but budget for it as headcount, not as free software.
• You have a concrete Elasticsearch version story. This matters more than the star count. The bundle's document/mapping model predates Elasticsearch 7's removal of mapping types, so it almost certainly encodes 5.x/6.x semantics. Running it against a modern cluster is likely to require surgery in exactly the code you least want to touch.

Look elsewhere — which is the recommended path — when any of the following holds:

• Provenance is unclear. The package name (stexaz/ongr-elasticsearch-bundle) and the repository (andriuspetrauskis/ElasticsearchBundle) don't match, and the "ongr" prefix ties it to the discontinued ONGR ElasticsearchBundle. This reads as a fork of a fork. Forks-of-forks rarely receive the upstream security backports that matter.
• Maintenance signal is absent. 0 stars, 0 dependents, last release 2017-10-27. Zero dependents is the sharper signal: nobody in the ecosystem depends on it, which means no user community will surface bugs before you do, and no one will fix them.
• It's the wrong framework. Symfony bundle, Laravel product — this alone is disqualifying.
• Security posture matters. A decade-stale dependency in the request path of a search feature is an unowned attack surface you'd have to defend in an audit.
• Better-supported alternatives exist. The official elasticsearch/elasticsearch client is maintained by Elastic and tracks cluster versions; Elastica is a long-standing community abstraction; Laravel Scout gives you a framework-native path. All three have the thing this package lacks: someone else's incentives aligned with keeping it working.

How to Pitch It (Stakeholders)

Bottom line: do not adopt. This is a decline, not a deferral.

To executives: the package is an integration library that would sit between our application and our search cluster. It has had no release since October 2017, has no downstream users, and its upstream lineage traces to a discontinued project. Adopting it would mean we inherit maintenance of an eight-year-old dependency ourselves — roughly the cost of building the integration in the first place, but with a worse starting point and no upstream. The licensing (MIT) means we could fork it; that's not a permission problem, it's a "who is on call for this" problem. It is also a Symfony component and does not fit our Laravel stack.

To engineering: treat this as a skip, and use the review time on the real decision — official elasticsearch/elasticsearch client versus a framework-native driver, with an explicit position on cluster version and reindexing. If we already have it in a legacy Symfony service, the ask is a remediation ticket with an owner and a date, not a new investment.

What I'd want before revisiting (and I don't expect to): a named internal maintainer, a fork with passing CI against our target Elasticsearch version, and evidence the mapping model survives ES 7+. Absent all three, the answer stays no — and the cost of saying no today is a week of integration work, versus the cost of saying yes being an unowned dependency in a user-facing feature.