Statamic Variable Number Fieldtype Laravel Package

Technical Evaluation

Architecture fit

• mitydigital/statamic-variable-number-fieldtype is a Statamic addon, not a standalone Laravel package. Its integration surface is the Statamic control panel (a custom Fieldtype) plus the Antlers/Blade rendering layer of a Statamic site. It inherits Statamic's Laravel service-provider bootstrapping and addon manifest discovery, so it imposes no new architectural pattern on the application.
• Blast radius is intentionally small: a Fieldtype touches content editing and field data serialisation, not routing, auth, queues, or persistence. That makes it a low-risk dependency from a platform-architecture standpoint.
• The constraint that matters is coupled versioning: Statamic addons typically pin their major version to the Statamic major version. This package is now in lockstep — 2.x for Statamic 5, 3.x for Statamic 6.

Integration feasibility

• 3.0.0 is a single-change release: Statamic 6 support (PR #2). Mechanically, adoption is a Composer constraint bump plus the corresponding Statamic 6 upgrade — there is no independent "adopt this package" motion.
• The real work is not the package. It is the Statamic 5 → 6 platform upgrade (Laravel and PHP baseline, CP asset pipeline, addon ecosystem parity). This fieldtype is one line item on that checklist.
• Feasibility hinges on two unknowns that must be confirmed from composer.json rather than inferred from the changelog: the exact statamic/cms constraint in 3.0.0, and whether Statamic 5 support was dropped (a major bump strongly implies yes, but the notes do not state it).

Technical risk

• Lockstep upgrade risk (high): if 3.0.0 drops Statamic 5, there is no version of this addon that supports both platforms. Staging and production must cut over together with the CMS upgrade; a partial rollout produces an unresolvable Composer graph.
• Data/rendering regression risk (medium): Fieldtypes persist values into content files (Markdown/YAML front matter). Any change to stored value format, null handling, or default output between 2.1.0 and 3.0.0 would surface as silently altered content rather than an error. The changelog does not claim a data-format change, but it does not disclaim one either.
• Maintainer concentration (medium): single-maintainer, single-purpose addon. Low bus factor, but also a very small code surface and a permissive fallback (replace with a core Number fieldtype or a hand-rolled field if the addon stalls).
• Changelog opacity (medium): a major version with a one-line changelog and no upgrade guide or breaking-change callout is the primary risk signal here, not the code change itself.

Key questions

1. Does 3.0.0 drop the statamic/cms ^5.0 constraint entirely, or is it widened to ^5.0|^6.0?
2. Are there any breaking changes beyond the Statamic constraint — field settings schema, stored value format, Antlers/Blade output, or CP component API?
3. What are the PHP and Laravel minimums imposed transitively by Statamic 6, and does our runtime meet them?
4. Is 2.1.0 still receiving security/patch releases for teams that defer the Statamic 6 upgrade?
5. Is there a documented upgrade guide or test fixture set we can validate existing content against?

Integration Approach

Stack fit

• Assumes a Statamic-based Laravel application. In a non-Statamic Laravel codebase this package has no applicability and should be rejected at triage.
• Fits cleanly wherever the current 2.x line is already in use for a "variable number" input — the fieldtype's role is unchanged; only its host platform version moves.

Migration path

• Treat this as a sub-task of the Statamic 6 upgrade, not a standalone dependency bump. Sequence: inventory all addons → confirm each has a Statamic 6-compatible release → upgrade Statamic and all addons in one Composer transaction → run content regression checks.
• Upgrade order within the transaction: bump statamic/cms and this addon together; do not attempt to resolve intermediate states. Expect and plan for a composer update that must be run with --with-all-dependencies to avoid partial resolution.
• Pre-upgrade: snapshot the content repository (it is file-based, so a branch or tag is sufficient) and export a sample of entries using this fieldtype as a before/after diff baseline.

Compatibility

• Verify the full matrix before committing: PHP version, Laravel version, Statamic version, and any other addons that share the CP asset build.
• CP-side compatibility is the most likely place for a surprise: a Fieldtype ships a Vue component, and CP component API shifts between Statamic majors are the usual source of "field renders blank" regressions.
• Confirm behaviour on both fresh installs and existing content — the second is where stored-value compatibility shows up.

Sequencing

1. Confirm answers to the key questions above; if 3.0.0 is Statamic 6-only, place this work inside the CMS upgrade epic with no separate delivery date.
2. Validate in a staging environment with a production content snapshot.
3. Diff rendered output and stored front-matter for the sampled entries against the 2.1.0 baseline.
4. Release with the CMS upgrade; keep the previous release branch tagged for rollback.

Operational Impact

Maintenance

• Near-zero ongoing maintenance between upgrades: no configuration, no background processes, no migrations. Cost is concentrated entirely at major-version boundaries, which for this package means Statamic majors.
• Cadence expectation: this addon's releases will trail Statamic majors by days-to-weeks. Budget for a lag between Statamic 6 GA and addon availability if the upgrade is time-sensitive.

Support

• Upstream support is GitHub issues against a single-maintainer repository — no vendor SLA, no commercial backing. Acceptable for a fieldtype; not acceptable if the fieldtype becomes load-bearing for a critical editorial workflow without a documented fallback.
• Internal ownership should sit with the team that owns the Statamic platform, not distributed to feature teams.

Scaling

• Negligible runtime scaling impact: a Fieldtype participates in CP form rendering and content augmentation only, not in high-traffic request paths, unless the field is queried or sorted in listings. If it is used in filters/sorting on large collections, validate query behaviour under Statamic 6 separately.

Failure modes

• Composer deadlock: addon constraint conflicts with another Statamic 6 addon, blocking the whole upgrade. Mitigation: full addon inventory and constraint audit before starting.
• Silent content drift: stored values reinterpreted under 3.0.0, producing wrong-but-valid output. Mitigation: before/after diff on a content sample; this is the failure mode most worth engineering against because it will not throw an error.
• CP field regression: field renders blank or non-interactive post-upgrade while content remains intact. Mitigation: editorial smoke test on a staging copy covering create, edit, and save.
• Rollback ambiguity: if the addon and CMS are upgraded together, rollback requires reverting both plus the content branch. Mitigation: tag the pre-upgrade state explicitly.

Ramp-up

• Low for engineers already fluent in Statamic addon conventions; the package is small and single-purpose.
• The real ramp-up cost is editorial, not technical: content authors need a short verification pass post-upgrade, and the CP field should be included in the sign-off checklist rather than assumed working.
• Recommend a brief written note in the upgrade runbook capturing the Statamic 5 ↔ 6 / addon 2.x ↔ 3.x mapping, so the next major cycle does not re-derive it.