Elastica Bundle Laravel Package

Product Decisions This Supports

• Search feature scoping — build vs. buy vs. integrate. This package is squarely an integrate decision: it is the glue layer between a domain model and an Elasticsearch cluster. Adopting it means choosing not to hand-roll index creation, mapping definition, alias swapping, bulk reindexing, and incremental sync. On a first search feature that is realistically 2–4 engineer-weeks of saved work — but only if the framework matches.
• Roadmap sequencing. It enables a phased search rollout: ship basic full-text search on entity-to-index population first, then layer facets, suggestions, and relevance tuning in later sprints without re-architecting the integration.
• Framework positioning (the dominant decision). Despite the "Laravel/PHP package" framing, FOSElasticaBundle is a Symfony bundle — a Bundle subclass with a DI extension, console commands, and Doctrine event subscribers. There is no service provider, facade, or config publishing. It does not plug into Laravel. The PM decision it actually informs is "is this service a Symfony service?" — and if not, the decision is redirected to Laravel Scout with an Elasticsearch driver, or a thin owned service around the official elasticsearch/elasticsearch client.
• Which artifact we standardize on. With 0 stars and 0 dependents, fos-gregooz/elastica-bundle reads as a personal fork or mirror, not the canonical package. The real upstream is friendsofsymfony/elastica-bundle. That is a procurement-level decision, not an engineering detail: it determines who owns our indexing path.
• Client-layer commitment. Adopting this pins the team to Elastica, an abstraction over the official PHP client. That has downstream consequences for Elasticsearch 8.x/9.x compatibility, OpenSearch migration optionality, and how much of the query DSL the team can reach directly. It is a one-way door worth naming explicitly.

When to Consider This Package

Consider it when:

• The application is Symfony, not Laravel, and the team wants declarative, config-driven mapping of Doctrine entities to Elasticsearch indices.
• You need out-of-the-box index population and repopulation tooling — bulk indexing of existing records plus live updates via entity listeners — rather than writing sync jobs yourself.
• The team is small and would rather adopt a convention-driven bundle than maintain a bespoke Elasticsearch service layer.
• You are on an Elasticsearch major that the pinned Elastica release explicitly supports, and you do not need bleeding-edge ES features.

Look elsewhere when:

• You are on Laravel. This is the dominant disqualifier. Symfony's kernel/DI compiler-pass machinery is technically bootstrap-able inside Laravel and operationally indefensible — the ramp-up is measured in weeks and buys nothing reusable.
• You intend to pin this repository specifically. Zero stars and zero dependents means no community review, no CVE response path, no release discipline, and no guarantee the repo survives. If the Symfony path is chosen, evaluate upstream and vendor any needed patch into a repo you control.
• You need Elasticsearch 8.x/9.x or OpenSearch on the official, actively maintained PHP client. Elastica lags the official client's feature surface, and that lag gates your cluster upgrade cadence rather than the reverse.
• Search is a core differentiator requiring fine-grained analyzer control, custom scoring, or vector/semantic search. At that point a thin, owned integration layer beats an opinionated bundle.

How to Pitch It (Stakeholders)

For executives: This is an integration library, not a product. It removes boilerplate around index definition, population, and data sync — realistically a few engineer-weeks of savings on a first search release. Two facts should govern the business decision: it is Symfony-only, so it is not a candidate for a Laravel codebase, and this particular copy has zero community adoption, so it carries maintenance risk with no support path. Recommendation: treat it as a reference architecture for what our search integration must do, then pick the implementation — Laravel Scout driver, upstream FOSElasticaBundle, or a small owned service — based on our actual framework and Elasticsearch version. Budget for eventually owning the indexing layer regardless, since upstream is also low-velocity.

For engineering: The bundle provides config-declared mappings, Doctrine listeners for incremental indexing, and populate/reset console commands on top of Elastica. Do not pull the zero-star fork as a dependency — diff it against friendsofsymfony/elastica-bundle at the nearest matching tag, PR anything generalizable upstream, and vendor the residue locally if it is genuinely necessary. Confirm the pinned Elastica release supports our target Elasticsearch major before committing. On Laravel this is a non-starter: build a queued indexer service against the official client, and if we want model-driven syncing, benchmark Scout's populate ergonomics against what this bundle offers before choosing. Design the read alias and a queue-backed indexing trigger from day one — synchronous listener indexing puts Elasticsearch on the critical path of every write, and that is the single most common production incident in this bundle family.