Symfony Bundle Laravel Package

Product Decisions This Supports

• Vendor lock-in avoidance for search. Schranz Search (the underlying php-cmsig/search, formerly SEAL) exposes a single abstraction over Elasticsearch, OpenSearch, Meilisearch, Solr, Algolia, Typesense, Redisearch, and more. This bundle wires that abstraction into Symfony's DI container. The core PM decision it enables: which search engine we run becomes a configuration choice, not a rewrite.
• Multi-engine roadmaps. You can develop against Meilisearch locally, ship Elasticsearch in production, and keep Algolia as a fallback — without three codebases. That's a real cost/velocity lever for teams that anticipate changing scale, cost, or hosting constraints.
• Build vs. buy on the adapter layer. If your roadmap touches 2+ search engines (e.g., self-hosted for cost, managed for reliability, or per-tenant engine choice), writing and maintaining N adapters is a hidden tax. Adopting an abstraction is cheaper than building one, provided the abstraction is actively maintained.
• Feature use cases: CMS/content search, e-commerce catalog and faceted search, documentation search, multi-tenant search where different customers get different backends, and migration off a legacy engine.
• Symfony-only signal. This is a Symfony Framework Bundle — it is not a Laravel package. For a Laravel codebase, this is not a fit out of the box; the underlying schranz-search/search core library is framework-agnostic and could be integrated manually, but you would be writing the Laravel glue yourself.

When to Consider This Package

• You are on Symfony and already using (or willing to use) the php-cmsig/search abstraction. The bundle's value is almost entirely DI wiring and configuration — without the parent library it does nothing.
• You genuinely need engine portability — the abstraction's cost (an extra indirection layer, a lowest-common-denominator API surface) only pays off if you actually run or plan to run more than one engine, or expect to migrate.
• You are comfortable with a small-ecosystem dependency. 15 stars on this repo is not the right metric — the parent project carries the community — but this split-out repo is READ-ONLY, signalling the bundle has been folded back into the schranz-search/search monorepo. Adopt the monorepo package, not this archived shim. Verify the current install path, version, and maintenance cadence before committing.
• Look elsewhere if: you are on Laravel (framework mismatch); you are committed to a single engine for the foreseeable future (direct SDK is simpler and exposes more engine-specific features); you need advanced engine features (complex aggregations, custom analyzers, vector/hybrid search) that a common abstraction tends to flatten; or your organisation requires a large, well-staffed dependency (this is a solo/small-team OSS project — bus-factor risk is real).
• Risk mitigation: pin versions, keep search calls behind your own domain interface so you can swap the abstraction out, and confirm the maintainer is responsive to issues before production adoption.

How to Pitch It (Stakeholders)

For executives: This is a search-abstraction layer that reduces strategic lock-in. It lets us change search vendors (Elasticsearch, Algolia, Meilisearch, Typesense, etc.) via configuration rather than engineering rewrites — lowering switching costs and giving us negotiating leverage on vendor pricing. It's MIT-licensed with no vendor fees. Key caveats: it only applies if we are on Symfony, it's a small open-source project (dependency risk to acknowledge), and this specific repository is archived into a monorepo — so the real decision is "adopt schranz-search/search," with this bundle as an integration detail.

For engineering: The bundle provides Symfony DI wiring and configuration on top of the framework-agnostic schranz-search/search core, giving a single SearchInterface across many engines. Benefits: config-driven engine choice, easy dev/prod parity (Meilisearch locally, Elasticsearch in prod), and a clean seam for testing. Trade-offs: an abstraction layer can hide engine-specific capabilities; it's a small project with limited maintainer bandwidth; and the repo is read-only, so we integrate via the monorepo package. Recommendation: prototype on a non-critical search surface first, keep our own thin domain interface in front of it, and re-evaluate after validating the maintainer's responsiveness and release cadence.