Search Bundle Laravel Package

Technical Evaluation

Architecture fit: None. liip/search-bundle is a Symfony bundle, not a framework-agnostic PHP library. It assumes Symfony's bundle registration (AppKernel), dependency-injection container compilation, service tagging, and the Symfony event dispatcher — none of which exist in Laravel's service-container/provider model. There is no path to installing it via Composer into a Laravel application and having it boot. Any "integration" would be a rewrite of the package internals, at which point the package contributes nothing but a class-name convention.

Core value proposition is dead. The package's sole function is wrapping the Google XML/SOAP Search API. That API was deprecated years ago and discontinued; the repository description states this explicitly. The bundle is not a generic search abstraction with a pluggable backend — it is a thin adapter to a retired remote service. There is no configuration under which it returns results. This is not a "risk" item; it is a disqualifying fact.

Integration feasibility: 0/10. Compounding factors:

• Archived upstream — read-only, no PRs, no security advisories, no maintainer response.
• Last release 2016-07-22 — targets PHP 5.x and Symfony 2.x. It will not install cleanly against PHP 8.x (composer why-not will surface constraint conflicts), and even patched constraints would hit removed language features.
• Zero dependents — no downstream projects to borrow patches or migration notes from. 34 stars confirms no meaningful community.
• No Laravel precedent — no laravel-liip-search shim, no gist, no fork of note.

Technical risk: total, not partial. Four independent failure modes each sufficient to block adoption: wrong framework, discontinued upstream API, unsupported PHP runtime, abandoned/unpatched codebase. There is no residual technical component worth salvaging except possibly the idea of a provider interface, which is standard and better expressed by Laravel Scout.

Key questions for the requester:

1. What problem were you hoping this solves — Google web search results, or site-local search? Those have entirely different replacements.
2. Is there an existing dependency (a legacy Symfony service, a client contract) forcing this package into scope? If yes, name it — it may be a data-migration problem, not a search problem.
3. Does the 0.689 score or 7.07 "opportunity" figure originate from an automated vendor scan? If so, treat it as noise: the score appears to reward recency-adjacent metadata while ignoring the deprecation and archive flags. Recommend the scoring model hard-exclude archived repositories and any package whose remote dependency is documented as discontinued.
4. Is Google programmable search still a requirement? If so, the sanctioned path is the Custom Search JSON API with a billing-enabled API key — a direct HTTP client call, no package needed.

Recommendation: reject. Do not add to the dependency manifest, even behind a feature flag.

Integration Approach

Stack fit: incompatible by construction. The package presumes Symfony 2's kernel/bundle lifecycle. Laravel's equivalent seam is the service provider plus config/ publishing; there is no adapter layer that bridges the two, and building one would mean rewriting the bundle. The only reusable asset is the conceptual shape of a SearchProviderInterface — a pattern Laravel Scout already implements natively and more cleanly.

Migration path (recommended replacement):

• Site-local or model search → laravel/scout with the database driver for small datasets, or meilisearch/typesense drivers once relevance ranking or typo tolerance is needed.
• Elasticsearch/OpenSearch → laravel-scout-elastic (or elasticquent for a thinner integration).
• Programmatic web search (the original intent) → Google Custom Search JSON API via Laravel's Http facade, credentials in config/services.php, responses cached. ~50 lines, fully testable with Http::fake().
• Legacy Symfony code still in the estate → treat this as a strangler-fig migration boundary, not a bridge. Define the search contract at the HTTP/JSON layer so both sides can call it during cutover.

Compatibility: effectively PHP ≤7.x and Symfony 2.x/3.x. Nothing here is compatible with a modern Laravel 10/11 baseline (PHP 8.1+). No LTS overlap exists.

Sequencing:

1. Week 0 — do not install. Confirm the requester's actual search requirement (local vs. web) in writing.
2. Week 1 — spike the replacement behind an interface (SearchService contract) so the backend is swappable. Two days: one driver against the chosen engine, one against Http::fake() fixtures.
3. Week 1–2 — port any behavior worth keeping. Realistically nothing: audit the bundle for query-building or result-normalization logic; capture it as test fixtures, then delete.
4. Week 2 — hard-block liip/search-bundle in the dependency policy so it cannot be reintroduced by a future automated scan.

If a stakeholder insists on an interim evaluation, the deliverable is a one-page ADR documenting the rejection and the chosen alternative — not a working integration.

Operational Impact

Maintenance: full ownership, no upstream. An archived repo means the adopting team becomes the sole maintainer of a fork on day one, for a component whose only external dependency is already gone. Expected steady-state cost is not "occasional patches" — it is "the code does not run," followed by an inevitable rewrite. Every hour spent here is sunk.

Support: no maintainer, no issue tracker activity, no security advisories, no CVE monitoring. This matters beyond functionality: an archived package is a supply-chain blind spot that will fail dependency and security audits (SCA tooling will flag it as abandoned), and it will not be patched if a transitive dependency discloses a vulnerability.

Scaling: not applicable. There is no runtime to scale. If it did function, the architecture would push query volume through a third-party web API with per-request quota and cost — a poor fit for any high-QPS or latency-sensitive path, and one that couples your search availability to an external provider's terms of service.

Failure modes (all observed, not hypothetical):

• Hard failure at install: Composer constraint conflict against PHP 8.x / modern Symfony components.
• Hard failure at boot: no bundle registration mechanism in Laravel; container compilation errors.
• Hard failure at runtime: upstream API returns 4xx/410; all searches return empty or throw.
• Silent degradation: stale credentials or quota exhaustion, with no maintained error handling.
• Audit failure: SCA flags abandoned + archived; release gate blocks.
• Opportunity cost: team time diverted from a two-day replacement build.

Ramp-up: inverse of the usual curve. Because the package cannot be made to work, "ramp-up" is really the cost of the replacement path — roughly two engineer-days for a Scout-based local search, or half a day for a Custom Search API client. Engineer familiarity with Laravel Scout is already high, so the real onboarding cost is near zero; the risk is mis-onboarding, i.e., a team sinking a week into attempting to revive the bundle before concluding it must be replaced.

Net: the 7.07 opportunity figure should be read as a false positive from an automated scan. The correct portfolio action is a documented rejection plus a standing dependency-policy exclusion — cheap now, expensive to defer.