Webman Scout Laravel Package

Product Decisions This Supports

• Build vs. buy for search: erikwang2013/webman-scout is a Scout-style indexing layer for Webman (Workerman-based PHP), not Laravel proper. The core decision it informs is whether to adopt a thin, Scout-compatible abstraction over a search engine (Meilisearch / Algolia / Elasticsearch / database driver) instead of hand-rolling index sync, observers, and reindex jobs. Adopting it converts a multi-sprint build into a dependency plus configuration.
• Stack fit / architecture: Confirms whether the product's PHP services are on Webman. If the fleet is Laravel, this package is the wrong tool — the official laravel/scout is the correct default and this becomes a non-decision.
• Roadmap de-risking for search features: Facets, typo tolerance, relevance tuning, geo search and synonyms get pushed to the underlying engine rather than the product backlog. This lets you commit to "search quality" roadmap items without owning an in-house search team.
• Use-case gating: Best suited to catalog/marketplace listing search, internal admin entity search, and content lookup — i.e. read-heavy, model-shaped data. Poor fit for analytics/aggregation workloads or log search, which need a different query model.
• Dependency and upgrade policy: v2.2.1 is a patch release (2.2.0 → 2.2.1). It carries no stated breaking changes, no migration steps, and no new feature surface. That makes it a low-risk, routine lockfile bump — it should not trigger a roadmap review, a QA cycle, or stakeholder comms. Treat it as maintenance-cadence evidence, not as a capability change.
• Vendor/maintenance risk register: The release note is only a diff link with no described contents. That is a governance signal: you can adopt, but you must budget for reading source diffs at upgrade time rather than relying on changelog summaries. Pin exact versions and require a diff review in the upgrade checklist.

Assessment confidence: low-to-moderate. The only data point supplied is a patch-version changelog link with no described changes, so feature and compatibility claims above are inferred from the package's name and Scout-lineage conventions and should be validated against the repository README and composer.json before any adoption decision.

When to Consider This Package

Consider it when:

• The service is built on Webman/Workerman and you want Laravel-Scout-style model indexing without porting Laravel's search stack.
• You want engine portability — starting on a database or Meilisearch driver and later moving to Algolia/Elasticsearch without rewriting application code.
• Your team already knows the Scout API ( Searchable trait, toSearchableArray, search() ), so onboarding cost is near zero.
• Search is a secondary capability in the product — you want it working, not differentiated.
• You are comfortable with a small, likely single-maintainer OSS dependency and can absorb diff-review overhead.

Look elsewhere when:

• The application is Laravel — use laravel/scout; taking a Webman-targeted fork adds risk for no gain.
• You need enterprise support, SLAs, or a security-response commitment — this is community OSS; the opaque 2.2.1 release note is a weak signal for audit-heavy environments.
• You need out-of-the-box search UX (instant search UI, analytics, A/B relevance testing); the engine choice covers this, the package does not.
• Your workload is aggregation-heavy or log/observability-oriented rather than entity-document search.
• Your policy requires documented changelogs for every dependency change — this project's release notes do not currently meet that bar, which is a process cost you must explicitly accept.

How to Pitch It (Stakeholders)

To executives: This is a small, free dependency that lets us add real search to our Webman services without building an indexing pipeline ourselves — weeks of engineering avoided, and no new headcount. It also keeps us portable: if we outgrow our current search engine, we change a driver, not the product. The newly published v2.2.1 is a patch release with no breaking changes, so there is no upgrade project, no downtime, and no customer-visible impact. The one caveat worth stating plainly: the project publishes minimal release documentation and appears maintainer-light, so we mitigate with version pinning and a diff review at each upgrade rather than by paying for support.

To engineering: Scout-compatible API, model observers for automatic index sync, driver abstraction so engine choice stays a config concern. v2.2.1 is a straight patch from 2.2.0 — verify the diff, bump the lockfile, run the indexing smoke tests, ship. Because the changelog is just a compare link, the upgrade checklist item is "read the commit diff," not "read the notes." Confirm the driver matrix in composer.json against our PHP version before we commit, and confirm whether we're on Webman at all — if this service is Laravel, we stop here and use laravel/scout.