Search Module Laravel Package

Technical Evaluation

Architecture fit. anomaly/search-module is not a general-purpose Laravel search package — it is a module in the PyroCMS 3 / Streams Platform ecosystem. It hooks into the Streams data model (streams, fields, assignments, criteria) and exposes a system-wide search index that other Pyro modules register against via a searchable contract. As a result, it only fits an application that is already a PyroCMS 3 site or is deliberately built on anomalylabs/streams-platform. In a vanilla Laravel application the integration surface is effectively the whole CMS: adopting this module means adopting Streams as the persistence layer for searchable entities. That is a platform decision, not a dependency decision.

Integration feasibility. Mechanically straightforward in the intended context: Composer install, service-provider auto-discovery, publish config and migrations (search index table), register searchable models, run an index build/refresh command, and expose the search endpoint or admin UI. The real feasibility constraint is version alignment — PyroCMS 3 spans Laravel 5.x through later 8.x-era releases, and PHP 8.x compatibility cannot be assumed from a package with zero stars and zero dependents. Compatibility must be verified against the exact streams-platform constraint before any estimate is credible.

Technical risk. High relative to the value delivered:

• Single-maintainer, zero-signal package. 0 stars, 0 dependents, no meaningful community. No security advisory history, no issue triage velocity, no downstream pressure to keep it current.
• Deep coupling. Upgrading Laravel or Streams will cascade into this module; there is no abstraction layer that lets you upgrade independently.
• Index correctness is the hard part. Any bug in index refresh, soft deletes, or permission filtering manifests as silently wrong results — the most expensive class of search defect.
• Opportunity score (17.97) is the honest signal. It says "worth knowing about," not "worth building on." The realistic value is as a reference implementation for Streams-native search, or as a fork.

Key questions before committing:

1. Which streams-platform and Laravel/PHP versions does composer.json actually admit, and when was the last meaningful commit?
2. Is the index driver database-only, or is there an Elasticsearch/Meilisearch driver? What is the query path for large corpora?
3. How is authorization applied at query time — does the module respect per-stream and per-entry permissions, or is filtering left to the caller?
4. Is indexing synchronous on save, or queued? Is there a safe full-rebuild command suitable for deploy pipelines?
5. Multilingual and multi-site behavior — inherited from Streams or unsupported?
6. License and fork viability: can we vendor it, patch it, and ship it internally without upstream coordination?

Integration Approach

Stack fit. Fits a PHP/Laravel stack running PyroCMS 3, MySQL or Postgres, with queue workers available for indexing. It does not fit a modern Laravel 10/11 application without a substantial fork, and it does not fit a polyglot stack where search is a shared service across non-PHP clients.

Migration path. Treat this as a spike, not a rollout. Run it in a disposable branch against a production-shaped dataset, measure index build time, query latency, and result quality on real queries. In parallel, prototype Laravel Scout + Meilisearch or Typesense against the same dataset. Pick based on measured outcomes, not on repository presence. If the organization is already on PyroCMS, the path inverts: this module is likely the lowest-friction option and the spike becomes a hardening exercise.

Compatibility. Pin the module, streams-platform, Laravel, and PHP versions explicitly in composer.json and lock them. Add a CI job that builds against the pinned matrix and runs the module's test suite (if any) plus your own integration tests over index build and query. Assume you own compatibility: with zero dependents, no one else will discover the breakage for you.

Sequencing.

1. Confirm the PyroCMS/Streams baseline and whether the module's constraints admit it — kill the evaluation here if they don't.
2. Fork the repository into internal VCS, add CI, tag a version. This is a prerequisite, not an optimization.
3. Land migrations and index schema; verify rollback and re-run idempotency.
4. Define the searchable contract for your domain entities and register them; cap the initial scope to one or two high-value content types.
5. Wrap access behind an internal SearchService interface so the module is swappable. This is the single highest-leverage design decision — it converts a platform lock-in into a replaceable dependency.
6. Build the backfill/reindex path with batching, queue dispatch, progress reporting, and a dry-run mode.
7. Ship behind a feature flag, compare against the existing search for a defined period, then cut over.

Operational Impact

Maintenance. Budget for fork-and-own. With no upstream momentum, expect to carry patches, PHP/Laravel deprecation fixes, and Streams upgrade churn yourself. A realistic steady-state estimate is a few engineer-days per quarter, spiking sharply on any Laravel or Streams major upgrade. If the organization cannot name an owner for that, do not adopt.

Support. There is no vendor and no SLA. Assistance is limited to the PyroCMS community channels and reading the source. Incident response for search defects will be internal, from first report to root cause, with no upstream escalation path.

Scaling. The critical unknown is the index backend. A database-backed index degrades predictably: full-text queries over a large search_index table become the bottleneck, and synchronous indexing on write adds latency to content saves. Mitigations are conventional — queue the writes, batch rebuilds, add composite indexes on the search table, paginate aggressively, constrain result counts, and consider a read replica for query traffic. If volume is expected to grow past low-hundreds-of-thousands of indexed records, validate the query plan before committing; if the plan is unacceptable, that is the trigger to prefer an external engine behind the SearchService interface.

Failure modes to instrument:

• Index drift — content changed but the index did not; manifests as missing or stale results with no error. Requires a reconciliation job and a freshness metric.
• Failed or partial reindex — blocks deploys if run inline; must be resumable, batched, and non-blocking.
• Silent zero-results — the worst outcome, because it looks like "no matches" rather than an outage. Alert on zero-result rate deviation and on empty-index detection.
• Authorization leakage — if permission filtering is caller-enforced rather than baked into the query path, search becomes a data-exposure vector. Verify explicitly.
• Boot-order and migration conflicts — provider registration and migrations interacting with other Pyro modules; test in a clean install, not just an upgraded one.

Ramp-up. The module itself is small; the Streams mental model is not. Engineers need to internalize streams, fields, assignments, and criteria before they can reason about why a document is or isn't indexed — realistically one to two weeks to productive, longer to confident. That ramp-up cost is a property of the platform, not the package, and should be counted against the module's 0.3 score rather than attributed to it.

Recommendation. Adopt only if the application is already committed to PyroCMS 3 and a Streams-native index is materially cheaper than an external engine. Otherwise, use the repository as a reference for how Streams-native search is structured and build on Laravel Scout with Meilisearch or Typesense, keeping the same SearchService seam so the decision remains reversible.