Statamic Group Laravel Package

Technical Evaluation

Architecture fit

eminos/statamic-group is a Statamic addon (Laravel package) that plugs into Statamic's addon architecture — service provider auto-discovery, control-panel fieldtype/grouping registration, and Statamic's publishing/config conventions. It carries no independent runtime architecture of its own; its fit is entirely a function of the Statamic core version it targets. The v2.1.0 release is a compatibility release: it adds Statamic 5 support, which is the meaningful architectural signal here. Statamic 5 is a major core release (Laravel 11 era, PHP 8.2+), so "adds Statamic 5 support" is a non-trivial statement about the addon's API surface having been reconciled with the new core.

Integration feasibility

Integration is a Composer-level concern, and this release makes it feasible for Statamic 5 projects where it previously was not. There is no bespoke wiring: install the package, the addon registers itself, config is optionally published. The practical work is verifying the version constraint in composer.json accepts the intended Statamic major and that the addon boots cleanly in the target environment. For teams already on Statamic 4, the release is effectively a no-op unless they intend to move.

Technical risk

• Maintainer concentration: This is a small, single-maintainer community addon. Bus factor is the dominant risk, not code complexity.
• Freshness of the compatibility claim: Statamic 5 support arriving in v2.1.0 means the combination is newly exercised. Early adopters are the de facto test matrix.
• Constraint ambiguity: The release note does not state whether Statamic 4 support is retained or dropped. If the constraint was narrowed to 5-only, this is a breaking change in practice for 4.x consumers despite the minor version bump.
• Low blast radius: Scope is control-panel field organization, not data-plane or request-path logic, so a failure degrades authoring UX rather than the public site.

Key questions

1. Does composer.json in v2.1.0 allow both Statamic 4 and 5, or is it 5-only (a de facto breaking change)?
2. Is there a CI matrix exercising Statamic 5 (and 4, if claimed)?
3. What is the minimum PHP/Laravel floor introduced by Statamic 5, and does it match our platform?
4. Does the CP fieldtype rely on any Statamic internal APIs that were renamed in 5?
5. Who is the maintainer, and what is the release cadence and issue-response history?
6. Is there a documented upgrade path or is this additive-only?

Integration Approach

Stack fit

Target stack is Statamic 5 on Laravel 11 / PHP 8.2+. For teams on that stack, this release is the enabling artifact. For teams on Statamic 4 / Laravel 10, it is not applicable. Confirm our platform baseline before scheduling anything.

Migration path

Pin explicitly rather than floating: composer require eminos/statamic-group:^2.1 after the Statamic core upgrade, or hold at 2.0.1 if still on Statamic 4. If the constraint is narrowed to 5-only, treat the move as a coordinated upgrade — Statamic core and this addon must land together, not sequentially across separate releases.

Compatibility

The release note asserts Statamic 5 only. It does not assert Statamic 4. Until composer.json is inspected, assume the safe reading is "5 supported, 4 unverified in this tag" and plan accordingly. Also verify the addon's config/blueprint schema did not change between 2.0.1 and 2.1.0 — a compatibility bump sometimes carries incidental serialization changes that affect existing content.

Sequencing

1. Upgrade Statamic core to 5 and Laravel/PHP floors; validate the site independently of this addon.
2. Inspect the v2.1.0 composer.json constraints and changelog diff (v2.0.1...v2.1.0).
3. Bump the addon constraint in a branch; run composer update eminos/statamic-group.
4. Smoke-test control-panel authoring: create/edit entries using the group field, verify field data round-trips and existing content renders unchanged.
5. Promote to staging, then production; keep the 2.0.1 pin documented as the rollback point.

Operational Impact

Maintenance

Minimal ongoing maintenance from our side — a single Composer dependency with no configuration drift expected. The real maintenance exposure is upstream: a small addon with one active maintainer and infrequent releases. Track it in the dependency inventory as low-activity/single-maintainer so it is reviewed at each Statamic major, not continuously.

Support

Support is community-only via the GitHub issue tracker. There is no vendor SLA. For a control-panel convenience addon this is acceptable; we should not take a hard dependency on it for anything content-critical without a documented fallback (e.g., reorganizing blueprints to not require the grouping behavior).

Scaling

No runtime scaling concern. The addon affects the authoring/control-panel layer, not request handling or content delivery, so it does not participate in traffic scaling, caching, or queue behavior. Editor-count growth is the only axis, and it is not a bottleneck.

Failure modes

• CP-only degradation: A core API change breaks field rendering or blueprint parsing; editors see a broken form while the public site stays healthy. This is the most likely failure and is recoverable by pinning back.
• Silent data-shape change: Group field data serializes differently after the bump, causing content to display incorrectly until re-saved. Detect via a diff of a sample entry's raw data before and after.
• Dependency resolution conflict: A narrowed Statamic constraint collides with another addon's constraint, blocking composer update for the whole project.
• Abandonment: No release for the next Statamic major; forces us to fork or remove the addon.

Ramp-up

Low. Developers already fluent in Statamic will read this addon in well under a day; it is a thin CP-layer package with a conventional structure. The ramp-up cost is not in understanding the code but in establishing the upgrade-and-rollback runbook above, which is a few hours of platform work.