Search Bundle Laravel Package

Technical Evaluation

Architecture fit. This is the central finding: enhavo/search-bundle is a Symfony bundle, not a Laravel package. It is a subtree split of the Enhavo CMS monorepo, meaning its classes are written against Symfony's Bundle, DependencyInjection, HttpKernel, and service-container conventions, and almost certainly against Enhavo's own resource/entity abstractions. A Laravel application has no bundle registration mechanism, no Symfony DI container, and no Enhavo domain model, so there is no clean architectural seam for this package to occupy. Treat any Laravel use case as a near-zero fit unless the target application is already Symfony-based.

Integration feasibility. For a Symfony host that already runs Enhavo, integration is plausible but still gated on upstream coupling: search indexing is typically wired to Enhavo resource definitions, Doctrine entities, and CMS configuration, so the bundle is unlikely to operate as a standalone "add search to my app" component. For a Laravel host, integration would require reimplementing the Symfony bundle plumbing (service providers, config merging, container bindings) around classes that assume a Symfony runtime — a rewrite, not an integration. The repository is also marked READ-ONLY and is a split rather than an independently released library, which means versioning, changelogs, and issue tracking live in the parent repo.

Technical risk. High. Signals are uniformly weak: 2 stars, 0 dependents, maturity scored as "readme" (the published README is essentially a project blurb and a subtitle pointer), and an opportunity score of 25.46 against an overall score of 0.01. There is no published API contract, no documented search backend (Elasticsearch, Doctrine-based full-text, or otherwise), no version compatibility matrix, and no evidence of independent maintenance. The split-repo pattern creates a specific risk: fixes and breaking changes arrive from upstream without semantic-version signals on this artifact, so a composer update can change behavior unexpectedly.

Key questions.

• Which search backend does the bundle require, and is that dependency pinned or optional?
• Does it hard-depend on enhavo/enhavo core, resource bundles, or a specific CMS data model?
• Are releases tagged on this split repo, or must consumers track the monorepo branch?
• What is the upstream maintenance cadence and supported Symfony/PHP versions?
• Is there any abstraction boundary (interface-driven indexer/searcher) that could be consumed without the bundle scaffolding?
• What is the license/security posture of a subtree split with no independent advisory history?

Recommendation. Do not adopt for a Laravel codebase. For a Symfony/Enhavo codebase, evaluate only if Enhavo is already the CMS in place; otherwise build a thin search abstraction against a supported backend and keep the CMS dependency out of the critical path.

Integration Approach

Stack fit. Laravel and this package are structurally incompatible at the framework layer. The only realistic "fit" is a Symfony application already using Enhavo, where the bundle slots into the existing kernel and container. There is no Laravel service provider, no config publish tag, no facade, and no Laravel-style package discovery.

Migration path. Not a migration — a decision point. If the product requirement is "search over CMS content," the viable paths are (a) stay within Enhavo/Symfony and consume the bundle natively, or (b) in Laravel, integrate a first-class search stack (Laravel Scout plus a driver such as Meilisearch, Typesense, Algolia, or Elasticsearch) and keep the CMS out of scope. Porting this bundle is not a cost-effective migration; the effort is dominated by reverse-engineering undocumented CMS coupling, not by transport or wiring.

Compatibility. Unknown and unverifiable from the published artifact. There is no README-level statement of supported Symfony, PHP, Doctrine, or search-engine versions, and no dependents to infer constraints from. In a Symfony host, assume you must resolve the full upstream Enhavo dependency graph before a container will compile — a large, fragile surface for a package whose value proposition is narrow.

Sequencing. If a Symfony/Enhavo evaluation proceeds, sequence it as: (1) confirm the parent Enhavo install is healthy and version-pinned; (2) fork or vendor the bundle at a known commit to insulate against silent upstream changes; (3) stand up the required search backend and index a small content subset; (4) validate the searcher/indexer interfaces in isolation before wiring controllers; (5) only then expose query endpoints behind a feature flag. For Laravel, the sequence is the inverse: define the search contract first, select a supported driver, and treat this repository as out of scope.

Operational Impact

Maintenance. Ownership cost is disproportionate to value. Because this is a read-only subtree split, patches cannot be contributed here; they go upstream, and downstream consumers inherit upstream release timing. A team would need to pin commits, monitor the monorepo, and carry a vendored fork if local fixes are ever required — ongoing overhead for a component with essentially no community gravity behind it.

Support. Effectively zero independent support surface: 2 stars, 0 dependents, issue tracking redirected to the parent project, and a README that does not document behavior. On-call engineers would be debugging undocumented CMS internals rather than a public API. This is the dominant operational risk and should be treated as a hard constraint, not a soft one.

Scaling. Scaling characteristics are a function of the underlying search backend, which is not specified by this artifact. Do not assume the bundle contributes indexing strategy, batching, queueing, or replication semantics; plan to own those concerns explicitly, including reindex pipelines and index lifecycle management.

Failure modes. Anticipated failure classes: container compilation failures from unresolvable service definitions; silent index drift or staleness after content changes; search backend unavailability surfacing as unhandled exceptions in content paths; upstream breaking changes arriving without semver signal on this split; and the classic orphan-risk scenario where upstream maintenance lapses and the package must be forked or removed under time pressure.

Ramp-up. Steep relative to the payoff. Engineers must learn Symfony bundle conventions plus Enhavo's resource/data model plus the unspecified search backend before producing a working query path. For a Laravel team this ramp is entirely non-transferable — the knowledge acquired does not improve the primary platform. Budget the evaluation as a short timeboxed spike with an explicit kill criterion rather than an integration estimate.