Laravel Search Laravel Package

Technical Evaluation

Architecture fit mmanos/laravel-search is a self-contained Laravel 5 package: a service provider, a Searchable trait for Eloquent models, a search_index table migration, and artisan commands to build/refresh the index. Its default mode keeps all search state in the application database — no daemon, no additional infrastructure to operate — which makes it an attractive fit for an MVP or back-office/admin search where the corpus is small (roughly tens of thousands of rows) and relevance requirements are modest. The v1.0.5 release ("Fixed removed match type for elastic search") corrects an earlier assumption in this assessment: the package is not purely DB-backed. It carries an optional Elasticsearch code path, and this patch is a repair to that path. That gives two modes rather than one:

• Database mode (default, and the mode anyone would realistically use): weight-based scoring over LIKE-style matching. No inverted index, no stemming, no faceting, no typo tolerance, and query cost grows with the size of the index table.
• Elasticsearch mode (optional, and now demonstrably stale): an integration written against an Elasticsearch generation whose match types have since been removed upstream. The fact that the fix was needed at all is evidence the ES path had drifted from the Elasticsearch APIs it targets; the patch restores it to some working state, not necessarily to a currently supported ES version.

The composite score (9.28) still reflects a small, clean, MIT-licensed codebase and should not be read as a production-readiness signal. The opportunity score (6.74) and the long gap since the 2017 release date remain the decision-relevant inputs. Net effect of v1.0.5 on architecture fit: unchanged for the DB mode, marginally more interesting on paper for the ES mode, and not enough to change the recommendation.

Integration feasibility Low-to-moderate on a modern stack, high on a legacy one. The package targets Laravel 5.x and its composer.json will almost certainly constrain illuminate/support to 5.x and PHP to 5.5/7.0-era versions, which blocks installation on Laravel 9/10/11/12 (PHP 8.1+). It also likely calls helpers removed or renamed after 5.x (array_get, str_*, etc.). Integration onto a current Laravel version therefore requires a fork: bump constraints, replace deprecated helpers, add return types, re-run tests. On an existing Laravel 5.x application, integration is a same-day job on a single model.

v1.0.5 does not change the framework/PHP constraints — it is a one-line behavioral fix in the search-match layer, not a compatibility release. It neither unblocks modern Laravel nor introduces breaking changes. If anything it adds a scoping question: the ES path is now nominally maintained, which may tempt someone to adopt it, but adopting it means owning an Elasticsearch client generation alongside the Laravel fork.

Technical risk

• Abandonment (revised, still high). v1.0.5 is the first recorded activity since 2017-06-29. A single narrow bugfix after a multi-year gap is a pulse, not a maintenance cadence: no triage, no deprecation policy, no compatibility work, effectively no dependents. Treat it as still-abandoned for planning purposes; any defect beyond this one remains ours.
• Dependency drift. Framework and PHP upgrades will break the package before they break the rest of the app; it becomes a pin on the upgrade path. Unchanged by this release.
• Performance cliff (DB mode). LIKE-based matching over an index table degrades non-linearly; there is no planner escape hatch short of database full-text indexes, at which point the package is largely redundant.
• Elasticsearch drift (ES mode). The v1.0.5 fix confirms the ES integration is coupled to a match-type API that Elasticsearch itself has removed. That coupling will recur: ES majors drop mapping/query types on a regular cadence, and there is no evidence of a test matrix against supported ES versions. Running this mode means pinning an ES cluster version to whatever the patch happens to target.
• Correctness surface. Wildcard escaping, collation/charset behavior, and multi-byte text handling are the usual failure points for hand-rolled search and are unlikely to be covered by the package's tests. A patch touching query construction is exactly the kind of change that warrants characterization tests before merge.
• Implicit coupling. The fixed search_index table name can collide with existing application tables and complicates multi-tenant designs.

Key questions

1. What Laravel and PHP versions are actually in scope, and is a fork acceptable to own?
2. Corpus size, index growth rate, and query volume at peak — does a database scan stay under budget?
3. What is the relevance bar (exact-prefix lookup vs. ranked full-text), and is an external search engine (Scout + Meilisearch/Typesense, or Postgres tsvector/MySQL FULLTEXT) on the table?
4. (New) Is the Elasticsearch mode in scope at all? If yes: which ES major and client library does v1.0.5 actually target, does that version remain supported upstream, and who owns staying current with ES API removals?
5. What is the acceptable index staleness window, and is indexing synchronous on save or queued?
6. Single-tenant or multi-tenant, and does the fixed search_index schema accommodate isolation?
7. Who owns the fork, and what is the exit plan and timeline to a maintained alternative?

Integration Approach

Stack fit Best fit: Laravel 5.x monolith on MySQL/Postgres with a small, slowly changing catalog and internal users, using DB mode only. Poor fit: Laravel 10+, high-QPS public search, multi-language content, or any product where search relevance is a differentiator. If the application is already on a modern Laravel version, the honest recommendation remains Laravel Scout with a managed engine — and that recommendation is strengthened, not weakened, by v1.0.5: if you are going to operate an Elasticsearch cluster anyway, Scout is the maintained path to it, and this package's ES client is a fork you would be adopting for no additional capability.

Migration path Two viable routes:

• Fork-and-maintain (only if staying on Laravel 5.x or willing to invest ~1–2 engineer-weeks): vendor the package under a private namespace, update composer constraints, replace removed helpers, add PHP 8 compatibility, and write characterization tests around indexing and matching before touching behavior. Bring v1.0.5 into the fork as the baseline and diff it against the version currently in use — small patches to query construction are easy to misread.
• Replace (preferred on modern Laravel): map the Searchable trait contract (search(), index sync on save/delete, reindex command) onto Scout plus a driver. The trait's surface is small, so the call sites are few; the real work is the indexing pipeline and backfill, which Scout also standardizes. If the ES mode was the attraction, this route gets you Elasticsearch without owning a Laravel 5-era client.

Compatibility Validate against the exact database engine and collation in production — LIKE semantics, case sensitivity, and index usage differ between MySQL and Postgres, and MySQL 8 reserved words can break generated SQL. Confirm the package's test harness (Orchestra/Testbench version) matches the target framework; if not, budget for rebuilding tests. Check for table-name collisions with the existing schema migration history. For the ES mode, pin and document the ES server version alongside the package version — the v1.0.5 fix exists precisely because that pin was implicit.

Sequencing

1. Spike (2–3 days): install the fork on the target stack, index one representative model, measure query latency at 1× and 10× current corpus size. Decide DB mode vs. ES mode explicitly at the end of this step; do not leave it ambiguous.
2. Triage v1.0.5 (half day): read the diff, confirm what "removed match type" means for the ES versions in scope, and add a regression test for it in the fork if ES mode survives step 1.
3. Schema and pipeline: land the index migration behind a feature flag; implement index-on-save/delete observers and a backfill/reindex artisan command with idempotency and batching.
4. Pilot: enable on one low-risk surface (admin lookup) with a hard dataset cap.
5. Instrument: log query duration, index lag, row counts, and zero-result rate.
6. Decide: go/no-go on broadening scope, with the replacement path (Scout + engine) pre-costed as the default if latency or relevance thresholds are missed.

Operational Impact

Maintenance Effectively permanent fork ownership. Budget recurring effort for PHP/framework upgrades, security review of the vendored code, and database compatibility. v1.0.5 does not change this: one patch release after a multi-year silence is not a maintenance guarantee, and it addresses one narrow defect rather than establishing a support cadence. There is no dependable upstream to consume fixes from; every change is ours to write, test, and carry. MIT licensing makes the fork legally clean but does nothing for the maintenance load.

Support Community-only. No maintainer triage, no SLA, no documented deprecation policy. Internal runbooks must be authored from scratch — indexing behavior, reindex cadence, and rollback procedures are undocumented and must be reverse-engineered from the source. If ES mode is adopted, the runbook must additionally record the ES server/client version pairing that the patched match-type logic assumes.

Scaling DB mode does not scale horizontally or vertically in a satisfying way: every query is a scan over the index table, and every write to a searchable model is an additional index write. Practical ceiling is a low-tens-of-thousands-row corpus with modest QPS; beyond that the mitigations are read replicas (partial help), database full-text indexes (which supersede the package), or replacement. ES mode moves the query load off the primary database but replaces it with a cluster to operate, size, and upgrade — a materially larger operational commitment than the package's default, and one this assessment would only sanction with a named owner. In both modes the index table/storage grows and becomes a backup-size concern over time.

Failure modes

• Stale or missing results when indexing is skipped — on bulk updates, direct SQL writes, transaction rollbacks, or failed queued jobs.
• Silent degradation as the corpus grows: searches still succeed but time out or return truncated result sets without an obvious error.
• Duplicate or orphaned index rows from non-idempotent reindex runs.
• Partial reindex failure leaving the index in an inconsistent state with no built-in checkpoint/resume.
• Wildcard/injection handling in user-supplied queries producing over-broad matches or expensive scans — the area v1.0.5 touched, so treat as freshly suspect.
• Elasticsearch version drift if ES mode is used: a routine ES upgrade removes a match type the client depends on, and search fails or silently returns nothing until the package is patched again — a cycle with a multi-year turnaround time on the vendor side.
• Schema migration conflicts from the fixed search_index table name.
• Upgrade lock-in when a framework upgrade is blocked by the package's composer constraints.

Ramp-up Low technical ramp-up — the API is a trait plus a search call, learnable in a day; the ES mode adds a second configuration surface but no conceptual complexity. The higher cost is institutional: someone must own the fork, understand the indexing pipeline end to end, hold the replacement decision, and — new as of v1.0.5 — track which Elasticsearch version the optional path is actually good against. Treat it as a tactical bridge with an explicit expiry, not a platform commitment.