Search Bundle Laravel Package

Technical Evaluation

Architecture fit. sylius/search-bundle is a Symfony bundle built for Sylius, a Symfony e-commerce platform. It is published as a read-only subtree split of the Sylius monorepo, it is archived, and it sits on the abandoned ongr/elasticsearch-bundle. Nothing in it targets Laravel: no service provider, no facade, no Eloquent integration, no Laravel-style config publishing. It compiles against Symfony's DI container and bundle lifecycle, Doctrine ORM, and Sylius' resource/event/grid contracts. For a Laravel codebase the architecture fit is effectively zero; for a Sylius codebase it is native but frozen. The TPM-relevant framing is that this package is a capability reference, not a dependency candidate — it documents what a framework-native, self-hosted e-commerce search layer looks like when a platform vendor ships one.

Integration feasibility. Three paths, only one of which is a real option:

1. Direct install into Laravel — blocked in practice. It drags in Sylius resource contracts, Doctrine, and Symfony bundle infrastructure Laravel does not provide. Any attempt reconstructs a Symfony kernel inside Laravel, which is an architecture decision no TPM should sign off on for search.
2. Design extraction — feasible and the intended use. The bundle's transferable value is its patterns: event-driven indexing on create/update/delete, explicit document mappings defining searchable/filterable/sortable fields, composed query filters and aggregations for faceted navigation, and result hydration into DTOs. These map cleanly onto Laravel Scout with Meilisearch/Typesense/Algolia/Elasticsearch, or onto the official Elasticsearch/OpenSearch client behind a service interface.
3. Ignore and buy/build natively — the pragmatic default for greenfield. Laravel-native search covers the same problem space with a maintained supply chain.

Feasibility of the product outcome (fast, faceted, relevant catalog search) is high. Feasibility of reusing this code is very low. Keep those two separate in any roadmap conversation — conflating them is how this package gets wrongly penciled into a plan.

Technical risk. High, and almost entirely supply-chain and upgrade-debt risk rather than runtime risk. Archived means no CVE response, no bug fixes, no PHP/Symfony/Elasticsearch-client version bumps. Because it is a subtree split, even a one-line patch means forking the Sylius monorepo and maintaining a divergent branch — an ongoing cost with no product upside. The dependency on the abandoned ongr/elasticsearch-bundle compounds this: you are inheriting a dead dependency tree, not just a dead package. Version constraints will assume PHP, Symfony, and engine-client majors that are already several releases behind, so the failure mode is hard Composer resolution conflicts that block unrelated upgrades — the risk surfaces as upgrade paralysis across the app, not as a search bug. Treat the 5 stars and 0 dependents as an artifact of the subtree split, not as adoption data; real usage lives in the Sylius monorepo and should be assessed via the parent project's health and whatever Sylius currently recommends in its place.

Key questions.

• What is the actual requirement? Catalog/browse filtering, full-text relevance, faceting, sorting, merchandising — or all of them? Scope decides whether a Laravel Scout driver suffices or whether you need a dedicated engine and a custom index schema.
• Which engine, and who runs it? The engine choice (Elasticsearch vs OpenSearch vs Meilisearch/Typesense vs managed SaaS) drives cost, ops burden, and the replacement decision far more than this bundle does. Decide engine first; the bundle becomes an input, not a gate.
• Is there a Sylius footprint anywhere in the estate? If a headless Sylius backend feeds a Laravel storefront, this bundle is relevant on the Sylius side only — and even then it should be replaced there, with integration over HTTP/queue rather than shared PHP code.
• Do we need to reuse code or reuse the design? Only the design is achievable at reasonable cost. Get this stated explicitly before any engineer starts a proof of concept around installing it.
• What is the team's Symfony/Sylius depth? Without it, both the extraction effort and any accidental adoption get materially worse.
• What is the migration deadline for anything already on it? "Archived" is a scheduled roadmap item, not a standing state.

Integration Approach

Stack fit. Treat the package as incompatible as a dependency and valuable as a reference implementation. It speaks Doctrine, Symfony compiler passes, and Sylius resource events; Laravel speaks Eloquent, service providers, queued jobs, and Scout. The problems overlap almost completely; the primitives do not overlap at all. The TPM move is to reframe the package in the backlog as research input to a search epic, explicitly not as an installable dependency, so it never enters a sprint as "integrate search bundle."

Migration path. Three steps; only the first touches the package, and it does so by reading, not installing.

1. Mine the design (time-boxed, 1–2 days). Extract the indexing pipeline shape — event-triggered indexing on create/update/delete, index-per-locale or index-per-channel conventions, query builder composition, filter/aggregation structure for facets, and result hydration into DTOs. Capture it as an internal spec. The single most valuable artifact to carry forward is the document mapping: which attributes are searchable, which are filterable, which are sortable. That is a product-attribute decision wearing an engineering costume, and it is the thing you would otherwise spend weeks rediscovering.
2. Re-implement on Laravel primitives. Model observers or domain events → queued indexing jobs → engine client or Scout, with the engine hidden behind an interface so it stays swappable. Search endpoints live in a dedicated service layer, not in controllers.
3. Backfill and reconcile. Full reindex command plus an index/DB reconciliation job. This is the piece teams consistently underestimate, and the piece the Sylius bundle does not hand you for free. Budget it explicitly.

Compatibility. Even as a reference, validate its assumptions against your target stack before citing it in a design doc: PHP version floor, the Symfony component majors vendored by your Laravel release, Doctrine presence (none in a standard Laravel app), and Elasticsearch/OpenSearch client majors. Expect the bundle to assume versions two or more majors behind current — which means its patterns are sound but its specific API usages are dated. Flag anything that depends on the abandoned ongr bundle as non-transferable.

Sequencing. Requirements and engine selection → gap analysis against maintained Laravel Scout drivers and managed providers (Meilisearch, Typesense, Algolia, Elastic Cloud) → design review using the bundle as one input → implementation → reindex and reconciliation tooling → load test → launch. Do not sequence a proof of concept around installing this package; budget the POC against the chosen engine instead. If a Sylius backend exists, sequence its search replacement as a separate workstream on the Sylius side, integrated over HTTP or a queue, never by sharing PHP code across the two frameworks.

Operational Impact

Maintenance. You either own everything or nothing — there is no middle state. Archived and read-only means no upstream fixes, no dependency bumps, no security patches, and a fork inherits a Sylius-monorepo-shaped maintenance burden for one bundle. The correct posture is zero ongoing dependency on this package; the cost is a one-time, time-boxed design-extraction effort you can put in a single sprint.

Support. None. No maintainer response, no advisories, no release cadence, no community to absorb a problem. The substitute is internal documentation written by the person who does the extraction — if that doc is not produced, the knowledge leaves with them and you have paid the extraction cost for nothing. Make the write-up a deliverable, not a nice-to-have.

Scaling. Largely neutral, because scaling characteristics come from the engine and the indexing pipeline, not from this bundle — provided you rebuild on Laravel-native primitives. The one coupling worth managing deliberately: subscriber-based indexing degrades badly under bulk operations such as catalog imports. The re-implementation must use queued, batched indexing from day one, with backpressure and retry semantics, rather than copying the synchronous event-subscriber shape the original assumes. Treat this as an acceptance criterion, not an implementation detail.

Failure modes (ranked by likelihood × cost).

1. Dependency resolution conflict on install or update, blocking unrelated upgrades — most likely first failure, most expensive to unwind, and the reason a strict "no install" rule belongs in writing.
2. Silent breakage on PHP/Symfony/engine-client upgrades with no upstream fix path — surfaces as an unexplained search outage weeks after an unrelated upgrade.
3. Doctrine/Sylius resource mapping collisions if Symfony pieces get coerced into the Laravel container by an optimistic engineer.
4. Event ordering and duplicate-index bugs if subscriber patterns are copied without the queueing discipline the original presumes.
5. Index drift — search results diverging from database state with no reconciliation job. Any Laravel-native rebuild must ship this explicitly; the package does not give it to you.

Ramp-up. High and mostly wasted for a Laravel team. Understanding the bundle demands Sylius domain knowledge (resources, channels, locale handling, grid system) on top of Symfony bundle internals, plus engine operational expertise — and none of that Sylius/Symfony knowledge transfers to your stack, because neither does the code. A competent Laravel engineer reaches a working Scout or engine-client integration faster than they reach a working understanding of this bundle. Budget for engine and indexing-pipeline expertise on the target stack instead; that is the durable investment.

Recommendation. Do not adopt as a dependency; do not schedule it as an integration. Fund a 1–2 day design review to extract the indexing pipeline and, critically, the document-mapping decisions as an internal spec, then implement natively on Laravel. Communicate it to stakeholders as a retired component that tells you what native search costs to own — a useful input to the build-vs-buy decision, and disqualifying as infrastructure. The package's real asset is a worked example of e-commerce search indexing in PHP: valuable as documentation, unacceptable as a line in composer.json.