Weave Code
Search Bundle Laravel Package
sylius/search-bundle
Sylius SearchBundle adds Elasticsearch-powered search to Sylius storefronts, enabling fast product indexing, configurable search indexes, and filtered catalog results for scalable e-commerce search.
[READ-ONLY] Subtree split of Sylius search bundle.
Frequently asked questions about Search Bundle
- Can I install sylius/search-bundle in a Laravel application?
- No. It is a Symfony bundle that depends on Sylius resource contracts, Doctrine ORM, and Symfony's dependency injection container and bundle lifecycle, none of which Laravel provides. There is no service provider, facade, config publishing, or Eloquent integration. Making it run would mean reconstructing a Symfony kernel inside Laravel, which is not a defensible architecture decision for search. Use it as a reference design and implement the same capability with Laravel Scout or the official Elasticsearch client.
- Is sylius/search-bundle still maintained?
- No, it is archived. The repository is a read-only subtree split of the Sylius monorepo, so even a one-line patch would require forking the parent project and maintaining a divergent branch. Archived status also means no CVE response, no bug fixes, and no PHP, Symfony, or Elasticsearch client version bumps. Treat the low star count and zero dependents as an artifact of the split rather than real adoption data.
- What does sylius/search-bundle actually do?
- It adds Elasticsearch-powered search to Sylius storefronts. It indexes products, defines configurable search indexes, and returns filtered catalog results for faceted browsing. Internally it uses event-driven indexing on create, update, and delete, explicit document mappings for searchable, filterable, and sortable fields, composed query filters and aggregations, and hydration of results into DTOs. Those patterns are the transferable part.
- What Laravel alternative should I use for faceted product search?
- Laravel Scout with Meilisearch, Typesense, or Algolia covers most catalog browse and filtering needs with a maintained supply chain. If you specifically need Elasticsearch or OpenSearch, wrap the official client behind a service interface and define your index mappings explicitly. Decide the engine first, because that choice drives cost and operational burden far more than any single package does. Then implement the same patterns this Sylius bundle demonstrates.
- How do I port the event-driven indexing pattern from sylius/search-bundle to Laravel?
- The pattern is straightforward to reproduce: hook into model created, updated, and deleted events and dispatch indexing jobs onto a queue. In Laravel you get most of this from Scout's Searchable trait, or you can write explicit observers plus queued jobs. Define document mappings separately from your Eloquent schema, listing which fields are searchable, filterable, and sortable. Keep the write path idempotent so re-indexing a document is always safe.
- What is the risk of the ongr/elasticsearch-bundle dependency?
- The bundle sits on ongr/elasticsearch-bundle, which is abandoned. You would inherit a dead dependency tree, not just a dead package, and its constraints assume PHP, Symfony, and engine client majors that are already several releases behind. The failure mode is usually hard Composer resolution conflicts that block unrelated upgrades elsewhere. That surfaces as upgrade paralysis across the application rather than as an obvious search bug.
- Does sylius/search-bundle support Laravel 10 or 11 and PHP 8.2?
- It does not target Laravel at all, so Laravel version support is not a meaningful question. It is built for Symfony and Sylius and its constraints track those release lines. Even inside a Symfony project, archived status means newer PHP and Symfony majors are not being validated against it. Do not plan a Laravel upgrade path around this package.
- What are the alternatives to sylius/search-bundle for Laravel e-commerce search?
- For a self-hosted engine, Laravel Scout with Meilisearch or Typesense is the lowest-friction option, and Algolia covers the managed SaaS case. For Elasticsearch or OpenSearch, use the official client with a thin repository or service layer plus a custom index schema. If you need merchandising and relevance tuning, plan an explicit mapping and query-building layer instead of relying on any single package. All of these are maintained and work on current Laravel releases.
- Should I use sylius/search-bundle when Sylius feeds a Laravel storefront?
- Only if the Sylius backend is a genuinely separate system, and even then replace the search bundle on that side. Integrate over HTTP or a queue rather than sharing PHP code across the two applications. Sharing a frozen Symfony bundle between a Sylius backend and a Laravel frontend adds coupling with no product benefit. Keep the search index and its schema owned by exactly one service.
- How should I test a search implementation inspired by this bundle?
- Test the write path and the read path separately. For indexing, assert that create, update, and delete events produce the expected documents, ideally against a real engine in a container rather than a mock. For queries, use fixture data to verify filters, aggregations, sort order, and relevance on known inputs. If you port the patterns to Laravel Scout, Scout's testing helpers plus one integration test against the engine cover most of it.
Weaver
How can I help you explore Laravel packages today?