Statamic Graphql Alternate Locales Laravel Package

Technical Evaluation

Scope of the change. Release 1.1.0 contains a single line: "Add support for Statamic 6." This is an additive compatibility release, not a feature or architecture change. The substantive signal is not the changelog text but what it implies: a major upstream CMS version has shipped, and this package now claims to run against it. Everything below is framed around that, and should be read as provisional — the release note carries no version matrix, no deprecation notice, and no test evidence.

Architecture fit. The package is a Laravel/PHP extension that lives inside the Statamic addon or package lifecycle (service provider registration, config publishing, likely an addon manifest and possibly Control Panel assets). That is a standard and well-understood shape in the Laravel ecosystem. Fit is therefore high provided the package respects Statamic's public extension points rather than reaching into internals. The single-line changelog gives no indication either way, and "support for a new major" is exactly the release type where internal-API coupling surfaces. This is the primary architectural question to resolve before adoption.

Integration feasibility. Low-to-moderate effort in the greenfield case: composer require, register the provider (or drop into addons/), publish config, run Statamic's cache/update commands. The brownfield case — an existing Statamic 5 application — is harder and is where the real cost sits, because the package upgrade cannot be done independently of the CMS upgrade. Composer's constraint solver will effectively couple the two: you cannot take this package at 1.1.0 while remaining on Statamic 5 unless the package keeps dual-version support in its constraints. That is a fact to establish from composer.json, not to assume.

Technical risk. Rated moderate, driven by unknowns rather than by anything alarming in the release itself.

Key questions to put to the maintainer (or answer from source):

1. Does 1.1.0 support Statamic 5 and 6 simultaneously, or has the floor moved to 6? What are the exact Composer constraints for statamic/cms, laravel/framework, and php?
2. Is there a documented test matrix per supported Statamic version, and is it visible in CI?
3. Does the package rely on any Statamic classes outside its documented extension API? Any @internal usage?
4. Are there any behavioural differences by Statamic version that the package normalises but does not document (e.g. fieldtype storage, augmentation, CP asset pipeline)?
5. What is the maintainer's support policy — how long will the Statamic 5 line receive fixes?
6. Is the 1.0.x line still receiving patches, and is there a planned 2.0 that drops Statamic 5?

Until questions 1 and 2 are answered, treat the release as "compatible in the maintainer's environment," not "compatible in ours."

Integration Approach

Stack fit. Assumes a Laravel application using Statamic as its content layer, with the package supplying additional functionality (fieldtypes, tags, modifiers, or CP tooling). Fit is native — same framework, same service container, same Composer dependency graph. There is no adapter or translation layer to own, which is a genuine advantage over integrating a non-PHP CMS extension. The one structural consideration: Statamic addons have a slightly different install and registration convention than plain Laravel packages, so confirm which shape this package uses before writing runbooks.

Compatibility. The version matrix is the whole ballgame and is currently undocumented. Before committing, resolve explicitly:

• Statamic 5 → package 1.0.x (presumed stable, presumed known-good)
• Statamic 6 → package 1.1.x (claimed, unverified by us)
• Whether 1.1.x spans both, and if so whether that span is tested or merely declared

If the package does not span both, the upgrade is atomic: Statamic 6 and package 1.1.0 land together or not at all. Plan accordingly — that turns a routine dependency bump into a coordinated platform upgrade.

Migration path. Recommend a branch-and-pin approach rather than in-place upgrading:

1. Freeze the current known-good pair (statamic/cms and this package) with exact constraints and commit the lockfile.
2. On a dedicated branch, raise the Statamic constraint to 6, let Composer resolve the package, and read the resulting lockfile diff — that diff is the compatibility answer.
3. Run the application's own test suite plus any Statamic content-model tests. Where coverage is thin (typically CP behaviour, fieldtype round-tripping, and cached/derived content), add targeted checks rather than relying on manual clicking.
4. Exercise the Control Panel manually for anything the package exposes there — fieldtypes and publish forms are the highest-risk surface and the least likely to be covered by automated tests.

Sequencing. Upgrade order matters and is not symmetric:

• Statamic 6 requires PHP and Laravel floors → verify hosting and CI images first, before touching Composer.
• Then Statamic 6 itself, in isolation, on a branch, so any failure is attributable.
• Then this package at 1.1.0 as a separate commit.
• Then dependent addons, which may lag Statamic 6 by weeks.

Doing Statamic and the package in one commit is tempting and will cost you a day of bisecting if something breaks. Keep them separate.

Rollback. Confirm that a Statamic major downgrade is actually reversible in your deployment — content-model and database changes made under 6 may not reverse cleanly. If it is not reversible, the staging environment must be a restored copy of production data, not a shared database.

Operational Impact

Maintenance. Modest but non-zero, and now coupled to Statamic's major-release cadence rather than the package's own. Expect this package to ship compatibility releases within days-to-weeks of each Statamic major, and to lag occasionally. Budget for one planned upgrade window per Statamic major, plus a small contingency for the addon ecosystem to catch up. The maintenance burden is low in steady state and spiky at CMS majors — plan for the spike, don't staff for the average.

Support. Depends entirely on maintainership model, which is not established here. Two things to nail down before this becomes load-bearing: the maintainer's stated support window for the Statamic 5 line, and whether there is a second contributor or sponsoring organisation. If it is a single volunteer maintainer and the package is on a critical content path, that is a real continuity risk that should be recorded, not glossed. Mitigation is cheap at this stage — vendor the source, or keep the ability to fork — and expensive later.

Scaling. No scaling impact from this release. Statamic 6 may change caching, indexing, or asset-transform behaviour underneath, which can shift performance characteristics, but that is an upstream concern rather than a property of this package. Re-baseline after the upgrade rather than assuming prior performance figures carry over.

Failure modes to watch. Ranked by likelihood × detectability:

1. Silent CP degradation — fieldtype or publish-form rendering breaks in ways that pass API-level tests and only surface when an editor tries to save. Low detectability, high editorial impact. Mitigate with a manual CP smoke pass on staging.
2. Content save corruption or truncation — the worst case; verify by round-tripping representative entries before and after, not by spot-checking.
3. Version-branch regressions — if dual support exists, users on Statamic 5 inherit changes intended for 6. Watch the issue tracker for a week after upgrading if you stay on 5.
4. Dependency resolution deadlock — an adjacent addon still pins Statamic 5, blocking the whole upgrade. Detectable early, cheap to check, annoying to discover late.
5. Cache/index drift — stale derived content after upgrade. Low severity, easy to miss, fixed by clearing caches; document the command in the runbook.

Ramp-up. Low for anyone already fluent in Laravel — service providers, config publishing, and Composer are familiar ground. The steeper curve is Statamic-specific: the addon lifecycle, the CP extension surface, and Antlers/data-layer conventions. A Laravel developer new to Statamic should expect a few days to be productive and roughly a week to be confident debugging content-layer issues. This is a package-level skill, not a platform-level one; no dedicated specialist is warranted unless it sits on the critical publishing path.

Recommendation. Suitable to adopt, with verification gated on two cheap checks: read composer.json for the actual version constraints (answering the dual-support question), and confirm CI tests both Statamic lines. If both come back clean, this is a low-risk upgrade on a normal cadence. If the package supports only Statamic 6 and you are on 5, do not upgrade opportunistically — schedule it as a platform upgrade with a staging rehearsal and a verified rollback. Given the changelog is one line long, the responsible posture is to treat 1.1.0 as plausibly compatible and let your own test suite, not the release note, be the arbiter.