- Is gbourgeat/elasticsearch-bundle a Laravel package?
- No. Despite being filed alongside Laravel packages, gbourgeat/elasticsearch-bundle is a Symfony bundle in the ONGR ElasticsearchBundle lineage. It ships a Symfony DI compiler pass, annotation-driven document mapping, and bin/console index commands, with no Laravel service provider, publishable config, or Artisan commands. Treat it as Symfony-only.
- Can I install this Elasticsearch bundle in a Laravel application?
- Technically yes, by booting symfony/dependency-injection and symfony/config inside a Laravel service provider, but that is a known anti-pattern. It imports a second DI container and a competing configuration system, making container resolution and debugging materially harder. The bundle's real value, Symfony service decoration and console tooling, would go unused while you inherit full Symfony coupling.
- How do I install this bundle in a Symfony project?
- Require it with Composer, register the bundle in config/bundles.php, then declare clients, indexes, and mappings in the bundle's YAML configuration. Document classes are mapped with annotations and repositories are consumed as container-managed services. Because the fork targets PHP 7.2, a modern Symfony app needs a fork-and-patch effort first.
- Which Laravel versions does this package support?
- None. The package has no Laravel integration and supports no Laravel version, because it is a Symfony bundle rather than a Laravel package. There is no ServiceProvider, no config publishing, and no Artisan surface. Laravel applications should look elsewhere.
- Which PHP and Elasticsearch versions does this bundle target?
- The fork is pinned for PHP 7.2, which reached end of life in November 2019, and carries ONGR-era elasticsearch/elasticsearch client semantics aimed at Elasticsearch 6.x and 7.x. Elasticsearch 8 enables TLS and security by default, removes mapping types, and changes the _doc API surface, so silent incompatibilities are expected rather than hypothetical. Verify the exact pinned client major before any decision.
- Is this package maintained and safe for production?
- The risk profile is high: zero stars, zero dependents, a single maintainer, no release cadence, and no security response path. Upstream ONGR is itself discontinued, with no dependency audit history or succession plan, so the package will not clear a standard third-party risk gate. If adopted at all, it should be quarantined with a scheduled removal.
- What is a good Laravel alternative for Elasticsearch full-text search?
- Bind elastic/elasticsearch-php v8 behind an internal SearchGateway interface exposing index, bulkIndex, delete, search, and reindexByAlias. If the requirement is document search with light filtering rather than faceted relevance, Laravel Scout with an Elasticsearch driver is a lower-glue option. Either path costs less than integrating a Symfony bridge.
- How do I configure connections and index mappings with this bundle?
- Search infrastructure is declared in bundle configuration: connection and client settings, index definitions, and mappings, all wired into the Symfony service container through dependency injection. That keeps indexing logic decoupled from domain code and lets you consume repositories as services. The trade-off is that this configuration lives in Symfony's config system, not Laravel's.
- How do I test an integration that uses this bundle?
- Testing is awkward outside Symfony, because exercising the bundle means booting the Symfony kernel and its DI container in your test harness. The practical approach is to define your own gateway interface and test against an in-memory fake, keeping the bundle at the edge. That also keeps the adopt-versus-build decision reversible.
- When would adopting this bundle still make sense?
- Only if part of your estate is a legacy Symfony application still on PHP 7.2, where the annotation mapping and repository layer genuinely save time. Even then, adopt it behind an interface, name a specific individual accountable for patching it to PHP 8.x and Elasticsearch 8, and schedule its removal. For a Laravel stack the recommendation is do not adopt.