Statamic Set Header Toggle Laravel Package

Technical Evaluation

Assessment basis: Derived from the v1.1.0 release notes and package identity (eminos/statamic-set-header-toggle) only. No repository contents, composer.json, test suite, or issue history were available for this review. Confidence is low-to-moderate; conclusions below are directional and should be validated against the actual manifest before adoption.

What this package is: A Statamic control-panel addon, not a general-purpose Laravel library. Its scope appears to be a UI affordance — toggling the visibility of set headers inside Statamic's publish forms (Replicator/Bard/Grid set stacks). It has no application-domain logic, no persistence layer, and no runtime role in request handling.

Architecture fit: Fit is binary. In a Statamic codebase it is a small, additive CP enhancement that does not alter content modeling or the data layer. Outside a Statamic codebase it is not applicable at all — this is not a package to evaluate for a plain Laravel application. The v1.1.0 change (added Statamic 5 support) is a compatibility widening, not an architectural change.

Integration feasibility: Low effort. Statamic addons are conventionally installed via Composer and auto-discovered through the addon manifest, so the expected path is composer require eminos/statamic-set-header-toggle with little or no configuration. There is no evident migration, service provider wiring, or env configuration implied by the release notes.

Technical risk: Low blast radius, but non-zero fragility. The risk profile is dominated by coupling to Statamic internals: CP addons of this type typically hook Vue components, publish-form DOM, or CP asset pipelines, all of which are private surfaces that Statamic does not guarantee across majors. A minor version adding Statamic 5 support suggests the maintainer is tracking core changes, which is a positive signal, but also confirms the addon is version-sensitive.

Key questions to resolve before committing:

1. Does v1.1.0 support Statamic 4 and 5 simultaneously, or is support now split across branches? The changelog is ambiguous.
2. What are the declared constraints for statamic/cms, php, and laravel/framework? Statamic 5 implies PHP 8.2+ and Laravel 11.
3. Is the Statamic 5 work a compatibility shim or a rewrite of the CP integration? This determines upgrade risk for existing installs.
4. Is the package licensed permissively (MIT et al.) and is the license compatible with our distribution model?
5. Test coverage and CI status: are there automated tests against multiple Statamic majors, or is this manually verified?
6. Maintainer health: single-maintainer project, contribution cadence, and issue responsiveness — relevant given this sits in the editorial UI.

Integration Approach

Stack fit: Only viable where Statamic is already the CMS. Target combinations are Statamic 4 on Laravel 10 / PHP 8.1–8.2, or Statamic 5 on Laravel 11 / PHP 8.2+. The v1.1.0 release is the enabler for the latter — before this release the addon would have been a blocker for any Statamic 5 upgrade.

Migration path: Treat this as a Statamic-major-upgrade unblocker, not an independent upgrade. The correct sequence is to include this package in the Statamic 5 upgrade wave rather than upgrading it in isolation. For teams already on Statamic 4, v1.0.0 remains functional; v1.1.0 should be a non-breaking drop-in because the change is described as added support rather than changed behavior — but verify the constraint set, since maintainers sometimes narrow support in the same release they widen it.

Compatibility and pinning: Pin explicitly and avoid floating constraints on a package whose support matrix spans two Statamic majors. A ^1.1 constraint is reasonable; confirm it does not silently resolve to a build that has dropped Statamic 4 if you still run 4 in any environment.

Sequencing recommendation:

1. Confirm composer.json constraints and whether a single version covers both Statamic majors.
2. Upgrade Statamic first in a staging environment, then install/upgrade this addon against it.
3. Validate the CP surface manually — specifically that set headers expand/collapse correctly in Replicator, Bard, and Grid fields, and that state persists as expected on save.
4. Only then promote to production, ideally behind a short editor-facing validation window.

Rollback: Trivial. Removing a CP-only addon requires no data migration and no schema reversal, so the change is cheaply reversible — a meaningful point in its favor for procurement.

Operational Impact

Maintenance: Very low ongoing cost in engineering hours, but with a concentration risk: small, single-maintainer, community-supported addon. Expect to own the upgrade testing yourself at each Statamic major. Budget a recurring line item at Statamic upgrade time rather than continuous maintenance.

Support: Community/GitHub issues only — no vendor SLA, no paid support tier implied. Acceptable for a cosmetic CP convenience; not acceptable for anything an editorial team would consider business-critical. Classify it explicitly as non-critical-path tooling so that on-call does not treat its breakage as an incident.

Scaling: Effectively neutral. No database, no queues, no external services, no front-end request-path involvement. Cost does not grow with content volume, traffic, or editor count. The only scaling consideration is CP asset payload, which is negligible at typical team sizes.

Failure modes to plan for:

• Silent CP degradation after a Statamic minor/patch upgrade — the toggle simply stops rendering or stops responding, with no error surfaced to the application. Detect via editor reports, not monitoring.
• Asset pipeline conflicts with other CP addons that patch the same publish-form components.
• Abandonment — the package stops receiving compatibility updates and becomes a blocker on a future Statamic major. Mitigation: keep the surface area small and be prepared to fork or replace with a few lines of custom CP CSS/JS, which is a realistic exit given the scope.
• Editor confusion if the toggle affordance is subtle or inconsistent across fieldtypes; low severity, but it is the actual user-facing value of the package.

Ramp-up: Near zero. Developers need only a Composer install and awareness that the package exists; there is no API, no configuration surface, and no conceptual model to learn. Editors require a one-line explanation or none at all if the affordance is self-evident. Documentation burden is minimal, which is proportionate to the package's scope.

Recommendation: Adopt as a low-risk, low-value convenience dependency if Statamic is already in the stack and the team is moving to Statamic 5. Do not treat v1.1.0 as a reason to adopt independently. Confirm the dual-major support claim in composer.json before pinning, and record the package as non-critical with a known fork-or-drop fallback.