Statamic Site Essentials Laravel Package

Technical Evaluation

Basis of assessment: a single data point — the v1.4.0 release note. No source, README, changelog, or prior assessment was available. Everything below that is not the version constraint itself is an inference that should be validated.

Architecture fit

• The package is a Statamic add-on (Statamic is a Laravel-based CMS), so it occupies a slot in the host application's Composer graph adjacent to Laravel and Statamic itself.
• v1.4.0 declares a hard floor of Statamic ^5.73 or ^6.4 and removes the 4.x line entirely. The constraint is disjunctive with no overlap, so the consuming environment determines exactly one branch.
• Practical consequence: the add-on inherits Statamic's own Laravel/PHP floors. Adopters are now pinned to a modern Statamic generation regardless of the add-on's own feature needs.

Integration feasibility

• Composer dependency resolution is the gate, and it is a clean binary: either the host is on Statamic 5.73+/6.4+ and installs, or it is on 4.x and does not.
• Straightforward for greenfield builds and for estates already on Statamic 5 or 6.
• Not feasible without a Statamic upgrade for anyone on 4.x — the add-on is no longer an independent variable in that decision.

Technical risk

• Semver concern (primary): dropping support for a dependency major is a breaking change for consumers, but it shipped in a minor release (1.4.0), not a major. Projects holding a caret constraint (^1.0, ^1.3) will be pulled toward 1.4.0 on the next composer update.
• Mitigating factor: Composer should fail dependency resolution outright rather than half-install, which is a loud failure. But it will block all unrelated dependency updates in that repo until someone intervenes — an outage on an unrelated PR is the realistic blast radius.
• No deprecation window is documented in the release note. It is unclear whether one was announced earlier or whether this is the first notification.
• Unknown whether 1.4.0 carries any other changes (features, fixes, security) beyond the constraint change.

Key questions for the maintainer

1. Is the 1.3.x line still maintained for Statamic 4, and for how long (patch window, security-only vs. full)?
2. Why was this shipped as a minor rather than a major? Was a deprecation notice published for an earlier release?
3. What is the actual driver — Statamic 4 end-of-life, or code that now depends on newer Statamic APIs?
4. Is there a published compatibility matrix (add-on version × Statamic × Laravel × PHP) and per-version CI coverage?
5. Are there any other changes in 1.4.0 not described in the note?

Integration Approach

Stack fit

• Laravel host + Statamic 5.73+ or 6.4+. Verify the corresponding Laravel and PHP floors for each branch before committing a target.
• Confirm the add-on's registration path (Statamic add-on discovery / service provider, any publishable config or migrations) is unchanged in 1.4.0 — the release note does not say, and this is cheap to check.

Migration path

1. Inventory first. For every app using the add-on, capture: installed Statamic version, installed add-on version, and the declared constraint (composer show, composer why). This is the only input that determines the branch.
2. On Statamic 4: immediately tighten the constraint to 1.3.* (or <1.4) so the intent is explicit in composer.json rather than an accident of the lockfile. Treat the Statamic 5/6 move as its own funded project, not a maintenance task.
3. On Statamic 5 but below 5.73: a within-major Statamic bump is the cheapest path; do that before touching the add-on.
4. On Statamic 6.4+: adopt 1.4.0 directly.

Compatibility

• Maintain a matrix of add-on version × Statamic version × Laravel × PHP, and record it in the repo README or an ADR. Statamic 5 and 6 are separate majors and cannot be co-resident in one app, so there is no dual-running scenario to design for.

Sequencing

• Constraint audit → Statamic upgrade (isolated change, own test pass) → add-on bump → regression pass over control-panel and content-rendering surfaces → deploy.
• Do not combine the Statamic major upgrade and the add-on bump in a single PR. If something breaks, you want to know which one did it.

Operational Impact

Maintenance

• The vendor now carries a two-major test matrix. Expect floors to move faster from here, which means constraint hygiene on our side becomes an ongoing obligation rather than a one-time fix.
• Cost on our side is concentrated almost entirely in the Statamic 4 → 5 upgrade; the add-on bump itself is near-zero effort.

Support

• Statamic 4 users are effectively self-supporting after this release. Get the 1.3.x patch window in writing before the next planning cycle, or plan to treat 4.x as unpatched.
• Escalation path for the semver question is the vendor's issue tracker; worth raising publicly since other consumers will hit the same composer update wall.

Scaling

• No runtime or performance implication from a version constraint. The relevant scale here is fleet-wide: how many repositories are on Statamic 4, and therefore how much upgrade work this release has just scheduled for us.
• If the count is non-trivial, this should enter roadmap planning as a dependency-modernisation item rather than be absorbed as maintenance.

Failure modes

• Loud: composer update fails resolution in a Statamic 4 app with a caret constraint. Blocks unrelated dependency work until the constraint is pinned. Detectable, low-severity, high-annoyance.
• Drift: loose constraints produce divergence between fresh dev installs and locked production builds. Pin explicitly.
• Quiet: an app left on 1.3.x keeps working but silently accrues unpatched-dependency risk as fixes land only on 1.4.x.
• Coupling: a future Statamic 5→6 move now necessarily drags an add-on review along with it. Acceptable, but should be reflected in upgrade runbooks.

Ramp-up

• No new API surface is implied by the release note, so engineering ramp-up is low — the work is constraint and upgrade planning, not learning a new interface.

Decision: adopt 1.4.0 for any estate already on Statamic 5.73+ or 6.4+; pin 1.3.x explicitly for anything on Statamic 4 and open an upgrade ticket. Obtain the 1.3.x support window and the semver rationale from the maintainer before the next planning cycle.