Search Bundle Laravel Package

Product Decisions This Supports

• Search & discovery roadmap scoping. The bundle defines the concrete feature surface of a native Elasticsearch-backed search layer for Sylius storefronts: product indexing, faceted navigation, filtering, sorting, and search-driven catalog browsing. That gives you a defensible "search v1" scope baseline — and a checklist of what you would otherwise have to spec from scratch.
• Build vs. buy for search infrastructure. This package represents the self-hosted, framework-native option in the classic trade-off against managed search (Algolia, Typesense Cloud, Meilisearch, Elastic Cloud). Its existence and its retirement are direct evidence for the cost side of "build/self-host": you own cluster operations, index schema, reindexing, and version upgrades in perpetuity.
• Catalog and PIM data-model decisions. Faceting only works on attributes that are mapped into the index, so index configuration is really a product-attribute decision: which fields are filterable, which are sortable, which are merchandisable. Use this as the forcing function to decide what your catalog actually needs to expose — that decision outlives any specific engine or package.
• Migration and decommission planning for existing Sylius shops. Because it is archived and sits on the abandoned ongr/elasticsearch-bundle, it drives roadmap decisions about when to move off, what replaces it, and how much upgrade debt accrues by staying. This is the single most actionable decision the package supports today.
• Stack standardization. Important caveat for the decision log: this is a Symfony/Sylius bundle, not a Laravel package. It has no service provider, facade, or Eloquent integration, and cannot be composer required into a Laravel app. So it supports Laravel-side decisions only by analogy — as a reference design for indexing pipelines and query/facet composition, never as an adoptable dependency.
• Competitive parity sizing. Faceted navigation, zero-result handling, and relevance tuning are table stakes in e-commerce. This gives a defensible "minimum viable search" definition for benchmarking against competitors and for scoping vendor demos.

When to Consider This Package

Consider it only in these narrow cases:

• Maintenance mode on an existing Sylius application whose Composer constraints already resolve to this bundle. Treat it strictly as patch-don't-extend; plan the exit.
• As a reference implementation, not a library. The indexed document model (Product, Taxon, variants, attributes), the event-driven indexing pipeline, and the query/filter/aggregation composition are the valuable artifacts. Reading the source and writing internal specs from it is a 1–2 day, time-boxed exercise with real payoff.

Look elsewhere if:

• You are on Laravel. There is no integration path that isn't a rebuild of a Symfony kernel. Use Laravel Scout with a driver (Meilisearch, Typesense, Algolia, Elasticsearch) or the official engine client. The patterns port; the code does not.
• You are greenfield on Sylius. Use current Sylius search components, a maintained community plugin, or a managed search SaaS.
• You need active maintenance, security response, or currency with modern PHP/Symfony/Elasticsearch versions. "Archived" plus a read-only subtree split means any patch requires forking the Sylius monorepo and maintaining a divergent branch. Expect hard dependency-resolution conflicts, not soft warnings.
• Your team lacks Symfony depth or Elasticsearch operational experience. Self-hosted search is a standing ops cost, not a one-time integration.
• You need capabilities beyond classic faceting — vector/semantic search, personalization, merchandising rules, A/B relevance testing. This bundle predates all of that.

Evaluation caveat worth stating explicitly in any decision doc: the 5 stars and 0 listed dependents are an artifact of this being a read-only subtree split — real usage lives inside the Sylius/Sylius monorepo. Do not read these metrics as adoption data either way. Assess the parent project's activity and whatever replacement Sylius currently recommends.

How to Pitch It (Stakeholders)

To executives: Search is a direct revenue lever in e-commerce — poor search shows up as lost conversion, not as a filed bug. This particular package is a retired component of the Sylius platform: it tells us what "native search" costs to own, but it is not something to build new roadmap on. The decision it should trigger is a funding one: budget for a maintained plugin (lower upfront cost, vendor dependency) or a managed search provider (higher run-rate, near-zero ops burden). Staying on an archived component is the only option with no upside — it is pure accumulating risk.

To engineering: This is an archived, read-only subtree split layered on an abandoned Elasticsearch bundle, with no security response and no version support. It is also a Symfony bundle, so it is out of scope as a Laravel dependency. Recommended posture:

• If we are already on it (Sylius estate): schedule migration as a roadmap item with a target quarter; quantify the upgrade debt before committing to any further feature work on that storefront.
• If we are on Laravel: do not attempt installation. Run a short, time-boxed design review (1–2 days) to extract the indexing pipeline shape — event-triggered indexing on create/update/delete, index-per-locale/channel conventions, query-builder composition, result hydration — and reimplement natively with queued/batched indexing and an explicit full-reindex and reconciliation job from day one.
• Either way: document the index schema decisions it encodes, because that mapping is the part worth carrying forward — and write it down, or the knowledge walks out with whoever did the extraction.