Statamic Live Search Laravel Package

Technical Evaluation

Evidence base. This is a baseline assessment; there is no prior assessment and no dependency, telemetry, or repository data beyond the v3.2.0 changelog. Conclusions below are inferred from the release notes and should be validated against the package's composer.json, CI matrix, and test suite before commitment.

Architecture fit. The package sits in the Laravel application layer with an explicit Statamic integration and a user-facing Search component. That places it on the request path for search traffic rather than in a background-only lane, so its failure modes are user-visible. The $q property indicates a Livewire-style stateful component, meaning the package participates in the front-end rendering lifecycle, not just server-side indexing. Fit is good for Laravel/Statamic shops already standardized on the framework; it is a poor fit for teams running Statamic 5 or Laravel ≤12 long-term unless backward compatibility is confirmed.

Integration feasibility. Low-to-moderate effort. Adoption is a Composer constraint change plus index configuration and a template/component wiring step. The real cost is validation, not installation: v3.2.0 broadens the support matrix to include two new majors (Statamic v6, Laravel 13), which multiplies the combinations that must be smoke-tested.

Technical risk.

• Support-matrix expansion in a minor release. Adding two major-version targets in a 3.2.0 bump is ecosystem-normal for Laravel packages (constraint widening), but it means the same artifact now claims compatibility across several framework generations. Untested combinations may resolve in Composer and fail at runtime.
• Statamic v6 major-version semantics. Statamic majors have historically carried breaking changes in templating, indexing, and addon APIs. "Support" here should be read as "constraint widened and smoke-tested," not "feature parity verified."
• $q type declaration is a potential BC break. Adding a type to a public component property can break consumer subclasses that assign non-string values, and can surface hydration/coercion errors in Livewire when the property is unset or null on first render. Low probability, non-trivial blast radius if the component is commonly extended.
• Silent search degradation. Search failures often present as empty result sets rather than exceptions, which is the hardest class of defect to catch in staging.

Key questions.

1. Does v3.2.0 retain support for Statamic v5 and Laravel 10–12, or was the constraint replaced rather than widened?
2. What PHP version floor is implied by Laravel 13 support, and does that conflict with the Statamic 6 floor?
3. Is the $q type declaration accompanied by a default value and null-safety, and is subclassing of the Search component a supported extension point?
4. What does the CI matrix actually cover — one combination per major, or the full cross-product?
5. Is there a documented upgrade note for Statamic 6, particularly around index schema and any re-index requirement?
6. Is this release a patch-level risk or does it warrant a major version under the project's own semver policy?

Integration Approach

Stack fit. Target only applications on a single, pinned major of both Laravel and Statamic. Do not adopt v3.2.0 as a means of running a mixed fleet (e.g., some apps on Statamic 5, some on 6) unless the widened constraint is verified — a single package version spanning both majors is convenient but concentrates risk in one upgrade.

Migration path.

1. Inventory current versions of PHP, Laravel, Statamic, and the package; record the exact constraint set.
2. Read the package's composer.json diff from v3.1.x to v3.2.0 to confirm whether Statamic 5 / Laravel 12 constraints were widened or dropped.
3. Upgrade in a branch on a staging environment with a production-like search index.
4. Re-index and diff result sets against the current version for a fixed query corpus.
5. Only then move to production.

Compatibility. Treat the framework upgrade and the package upgrade as separable decisions. If Laravel 13 or Statamic 6 is not otherwise planned, there is no reason to take v3.2.0 now — pin to the prior minor and defer. If a framework upgrade is planned, this package is likely the enabling dependency and should be sequenced accordingly.

Sequencing.

• Framework-first: upgrade Laravel/Statamic, then the package, when the package is not the blocker.
• Package-first: take v3.2.0 while still on the old framework to confirm backward compatibility, then upgrade the framework. Preferred when the widened constraint is confirmed as additive, since it isolates failures to one variable at a time.
• Do not bundle the $q typing change with a framework upgrade in the same release window; the search component's rendering behavior should be validated independently.

Operational Impact

Maintenance. A minor release that adds support for two framework majors signals an actively maintained package with a fast-follow cadence on ecosystem releases. That is a positive signal but also an ongoing tax: each new Laravel major will force another constraint review, and the team must budget a recurring upgrade checkpoint roughly annually. Pin exactly and upgrade deliberately rather than floating on ^3.0.

Support. Expect upstream support for Statamic 6 and Laravel 13 to be the priority going forward, with older majors aging out. Establish an internal policy for which framework majors are supported in production and confirm the package's deprecation timeline matches it. The absence of deprecation notices in v3.2.0 is reassuring but not a guarantee for v3.3+.

Scaling. Search is a latency-sensitive path. Adding Statamic 6 support may entail a different indexing backend or query layer, so throughput and result-quality characteristics should be re-measured after upgrade rather than assumed identical. Re-indexing is the main operational cost of a major Statamic move and should be scheduled as a discrete maintenance window with a rollback plan.

Failure modes.

• Hard failure: Composer resolves a dependency combination the package does not actually support; autoload or class-not-found at boot.
• Component failure: typed $q property hydration errors on first render or after a Livewire update, presenting as a broken search box.
• Silent degradation: search returns empty or stale results post-re-index; no exception, no alert.
• Subclass breakage: downstream customizations of the Search component throw a type error only when exercised.

Mitigations: a synthetic search canary against a known query set in production, alerting on zero-result rate rather than error rate, and a documented list of any local subclasses of the Search component.

Ramp-up. Low. This is a conventional Laravel package with a small public surface. A developer familiar with Laravel and Statamic should reach productive use in under a day; the meaningful investment is in building the regression harness for search results, which is worth doing once and reusing for every subsequent framework major.