Elasticsearch Bundle Laravel Package

Product Decisions This Supports

• Search as a roadmap item, not plumbing. This bundle is a Symfony integration layer over the official elasticsearch/elasticsearch PHP client — it wires the client into Symfony's DI container and exposes configurable client/index settings. Its value to a PM is that it lets the team treat search, faceted filtering, autocomplete, and relevance-ranked results as a product deliverable while the undifferentiated HTTP/serializer glue is already handled. It reframes the build/buy conversation around index modeling and relevance tuning — the actual product work — instead of transport wiring.
• A clear build-vs-buy answer for the integration layer. Elasticsearch itself is the "buy" decision. This bundle is only the Symfony glue, and it is a commodity: small, auditable, single-maintainer, zero dependents. The strategic investment belongs in index design, field mapping/analyzers, and relevance evaluation — not in the connector.
• Vendor and dependency risk framing. Zero stars, zero dependents, a single maintainer, a hard pin to PHP 7.2, and no release cadence make this a legacy-stack convenience, not a strategic dependency. This directly supports a "do not standardize on this" decision and points the platform team at the official client or a maintained bundle (e.g., FOSElasticaBundle in Symfony land; laravel/scout with an ES driver or a thin elastic/elasticsearch-php wrapper in Laravel land).
• A critical framing correction for the roadmap. Despite being filed here as a "Laravel/PHP package," this is a Symfony bundle (ONGR lineage) — no ServiceProvider, no config/search.php, no Artisan commands. In a Laravel stack you would consume roughly 40% of it and inherit 100% of its Symfony coupling. That fact belongs in the intake notes so the decision is made on the right stack assumption.
• Migration and upgrade planning. If the codebase is Symfony on PHP 7.2, the bundle can accelerate a search MVP — and simultaneously becomes a line item on the PHP 8 / ES 8 upgrade roadmap, since it must be replaced (or forked and owned) before either move. That trade-off is a planning decision, not a sprint task.
• Use cases it plausibly serves: internal admin search over moderate datasets, prototype/MVP search on a frozen legacy Symfony app, or low-traffic catalog search where relevance is "good enough" and the team already knows Elasticsearch.

When to Consider This Package

Consider it only when all of these hold:

• The application is already on Symfony with PHP 7.2 and cannot be upgraded in the current cycle. (For a Laravel stack: do not adopt — the value is locked behind Symfony compiler passes, DI service decoration, annotation mapping, and bin/console commands.)
• Search is a low-blast-radius surface — internal tooling, a prototype, a non-revenue feature — where a short-lived dependency is acceptable.
• Engineering has read the source (it is small and auditable) and confirmed it boots against your exact Symfony and Elasticsearch versions.
• A named owner has accepted the maintenance burden and there is a written exit plan (official client or FOSElasticaBundle) tied to the PHP 8 upgrade.
• You are not exposing it to untrusted configuration input.
• You have a SearchGateway interface in front of it so the bundle's types never leak into application/domain code — that interface is what makes the decision reversible.

Look elsewhere — as the default recommendation — when:

• The stack is PHP 8+ / current Symfony or Laravel. The 7.2 pin is a non-starter for new builds.
• Search is revenue-critical (storefront search, ranking, discovery). You need active security patching and a community to lean on.
• Security review or procurement sign-off is required. A single-maintainer package with zero dependents and no release cadence will not clear a standard third-party risk gate.
• You need observability, connection pooling, or multi-cluster support — the official client covers this; a thin legacy bundle likely does not.
• The honest alternative is available: elasticsearch/elasticsearch (or elastic/elasticsearch-php v8) plus a small, owned service/wrapper layer. That is the "build" side, it is small, and it survives the upgrade.

How to Pitch It (Stakeholders)

To executives: This is an Elasticsearch integration for Symfony, pinned to PHP 7.2. It is not a candidate for strategic adoption — no community, no dependents, a single maintainer — which means we would own all maintenance and security risk ourselves. Recommendation: do not standardize. Treat it as a tactical, time-boxed accelerant for a legacy-stack search prototype only, with a defined exit before our PHP 8 upgrade and a named owner on the hook for patching. Search is a product differentiator; the Symfony-to-Elasticsearch glue is not — spend the effort on index design and relevance.

To engineering: Use the official elasticsearch/elasticsearch client and wire it into the framework as a service — a few dozen lines we control, and it survives the PHP 8 migration. If you want a maintained bundle abstraction in Symfony, FOSElasticaBundle is the choice; in Laravel, laravel/scout with an ES driver or a thin client wrapper. Reach for gbourgeat/elasticsearch-bundle only on a frozen Symfony/PHP 7.2 app, only after reading the source, and only behind an internal SearchGateway interface with a removal ticket already filed. Put a real Elasticsearch container in CI before any production indexing code lands — mocked tests hide mapping, alias-swap, and items[].status failures.

Bottom line: For a Laravel stack, this is a no — the fork's value is trapped behind Symfony idioms and its abandonment profile (0 stars, 0 dependents, PHP 7.2) makes it a liability rather than an accelerant. For a legacy Symfony 7.2 app, it is a qualified, quarantined yes: adopt behind an interface, with a named owner and a documented exit. Either way, keep the glue boring, owned, and upgrade-path-compatible.