Documentation Search Laravel Package

Product Decisions This Supports

• CMS upgrade sequencing (Statamic 5 → 6). v2.0.0 explicitly targets Statamic 6, so this release is the gate that lets the platform upgrade move forward. Treat it as a dependency in the upgrade epic, not as an independent line item.
• Build vs. buy for the integration layer. A focused Laravel package that wires into Statamic's provider/binding layer is almost never worth rebuilding in-house. Adoption is the cheaper call unless the integration is core to your differentiation.
• Upgrade budget for a major version. The provider now returns references rather than objects. That is an internal-facing breaking change: anything that extends the service provider, overrides bindings, or resolves container entries expecting concrete objects needs an audit. Scope this as a half-day to two-day engineering task per codebase, not a regression risk to users.
• Extension-point strategy. If your product decorates or replaces the provider's bindings, returning references changes how you compose around it — more flexible for chaining/decorating, but code that type-hints on returned objects will need adjusting. This matters if you plan to customize rather than consume as-is.
• Support matrix and version pinning. Two supported majors now exist (v1 for Statamic 5, v2 for Statamic 6). Pin explicitly per environment and record which product versions sit on which track before the upgrade lands.

When to Consider This Package

Adopt when:

• You are on, or actively migrating to, Statamic 6 — v2.0.0 is the only version aligned with it.
• You need the integration it provides and want it maintained alongside Statamic's own release cadence rather than vendored in-house.
• You have a small number of call sites touching the provider/bindings, making the references-vs-objects change cheap to absorb.

Look elsewhere or defer when:

• You are staying on Statamic 5 for the foreseeable future — v1 remains the correct pin and v2 buys you nothing.
• Your codebase deeply extends the service provider or relies on object-returning bindings across many modules; the migration cost may exceed the value of upgrading now.
• You need formal support SLAs, security backports, or a multi-maintainer guarantee. Release notes this terse are a signal to check commit history, issue responsiveness, and test coverage before betting a platform upgrade on it.
• The integration is peripheral and a thin internal wrapper would be fewer moving parts than an external dependency with breaking majors.

How to Pitch It (Stakeholders)

For executives: This is the dependency that unblocks our Statamic 6 upgrade. It is a small, single-purpose package — low cost, low surface area, no licensing spend. The v2.0.0 release is a major version with one internal breaking change scoped to our own service-provider wiring, not to end users. Expect a small, bounded engineering effort rather than a project. The main strategic exposure is maintainer concentration: we should pin versions, keep our own tests around the integration, and avoid customizing more than necessary.

For engineering: v2.0.0 refactors the service provider to return references instead of objects and adds Statamic 6 support. Before upgrading: audit every place we extend or override the provider, resolve its bindings from the container, or type-hint on what those bindings return; update published config if the upgrade guide calls for it; and run the full suite against Statamic 6 in a branch. Keep v1 pinned on the Statamic 5 line until the 6 cutover is complete, and land the upgrade as a single PR with the framework bump so the two can't drift.