Statamic Uuid Laravel Package

Technical Evaluation

Architecture fit aryehraber/statamic-uuid is a Statamic addon, not a general-purpose Laravel package. It registers a UUID fieldtype so content entries, terms, and assets can carry generated identifiers. It has no persistence layer of its own — values live wherever Statamic stores content (flat-file or the content repository). Architectural footprint is therefore minimal, but relevance is binary: it only matters if the target stack runs Statamic.

Integration feasibility Installed via Composer with Statamic addon auto-discovery; no application wiring beyond adding the field to a blueprint. The v2.4.0 change is a single PR adding Statamic v6 support, which strongly implies a version constraint change rather than new behavior. Integration is straightforward if the stack is already on Statamic v6; otherwise this release is not installable.

Technical risk

• Version coupling (primary risk): the package must ship a release for every Statamic major. v2.4.0 likely raises the floor to v6 and may drop v5 — verify composer.json constraints before assuming a drop-in upgrade.
• Uniqueness is not enforced: the fieldtype generates a UUID but does not guarantee DB-level uniqueness. Anything consuming these values as durable external identifiers must not assume the field can't be duplicated or hand-edited.
• Maintenance concentration: small addon, low PR volume, effectively single-maintainer. Acceptable for a convenience fieldtype, not for a load-bearing identifier without a fork path.
• Data preservation: existing UUID values must survive the upgrade; this is a fieldtype swap, not a data migration, but it should be verified rather than assumed.

Key questions

1. Which Statamic major is in production, and is a v6 upgrade planned or already in flight?
2. Are these UUIDs consumed externally (public API IDs, webhook payloads, sync keys, analytics joins) or are they internal convenience only?
3. Does anything downstream require guaranteed uniqueness, and if so, who enforces it?
4. Does v2.4.0 drop Statamic v5 support? What are the exact PHP/Laravel constraints?
5. Do the stack's other addons also support Statamic v6, or will this one be blocked by a laggard?

Integration Approach

Stack fit Applicable only to a Statamic v6 stack on a compatible Laravel/PHP baseline. For a plain Laravel application this package is out of scope — the equivalent need is satisfied by Str::uuid() or a model-level UUID trait.

Migration path v2.3.0 → v2.4.0 is additive in intent (Statamic 6 support) but is a version-boundary release, not a feature release. Treat it as an upgrade-coupling decision: adopt it as part of the Statamic 5→6 migration, not on its own. Teams staying on Statamic 5 should pin to 2.3.x and take no action.

Compatibility Confirm the package's composer.json requirements (Statamic major, Laravel, PHP) against the runtime. Then confirm the rest of the addon set — SEO Pro, assets, forms, any custom addons — also declares Statamic v6 support. A single incompatible addon blocks the whole upgrade, so this addon is one input into a broader dependency-readiness check, not the gate itself.

Sequencing

1. Inventory all addons and their Statamic v6 readiness.
2. Upgrade Statamic in a branch; resolve the addon set together.
3. Bump this package to 2.4.0 in the same change.
4. Verify: new entries receive a UUID on save; existing entries retain their prior values unchanged; blueprint validation behaves as before.
5. Deploy as a single coordinated release with the Statamic upgrade.

Do not sequence this release ahead of the Statamic upgrade — installing it early will either fail resolution or silently pull an unintended version.

Operational Impact

Maintenance Low. Third-party maintained, no local code, no configuration. The recurring cost is tracking Statamic majors: every major upgrade requires a corresponding package release to exist before you can move. Pin the version explicitly rather than floating.

Support Community-supported via GitHub issues, no SLA. Appropriate for a non-critical fieldtype; if UUIDs become load-bearing, budget for the ability to fork and patch — the change surface is small enough that this is realistic.

Scaling Negligible. UUID generation happens on write; storage overhead is trivial; no additional infrastructure, queue, or service. Not a scaling consideration at any realistic content volume.

Failure modes

• Statamic major lag (most likely): addon not yet updated when the CMS upgrades → upgrade blocked or field broken. Mitigation: readiness check before every Statamic major.
• Duplicate or edited values: uniqueness not enforced; manual edits or imports can collide. Mitigation: treat the field as read-only in the control panel where used as an identifier, and enforce uniqueness downstream if it matters.
• Silent loss: removing or reconfiguring the field in a blueprint may orphan values. Mitigation: document which blueprints use it.
• Abandonment: low-activity project; no succession plan. Mitigation: fork-ready posture given the small surface area.

Ramp-up Trivial. A developer already familiar with Statamic fieldtypes can onboard in under an hour; there is no operational or infrastructure knowledge required. The only meaningful learning is upstream — the Statamic v6 migration itself, which is a separate and much larger effort.