Product Decisions This Supports
- Statamic version upgrade planning: This release directly de-risks an upgrade to Statamic 5.73+ (and forward-compatibility with Statamic 6). If your roadmap includes a CMS upgrade, this addon is now a green light rather than a blocker — the
Route [statamic.cp.blueprints.asset-containers.edit] not defined failure was a hard break in the control panel for any fieldtype usage.
- Build vs. buy for asset-container blueprint editing: The package fills a narrow but real gap — surfacing asset-container blueprint selection/editing inside the Statamic CP. The fix confirms the maintainer is tracking core route changes, which is the main risk with thin addons. Buying (adopting) remains cheaper than building and maintaining in-house route-resolution logic against a moving Statamic core.
- Support matrix / compatibility commitments: The release explicitly targets "older Statamic 5, 5.73+, and 6" via route-name resolution. This supports publishing a supported-versions statement to customers and setting a floor/ceiling on Statamic in
composer.json.
- Dependency hygiene and supply-chain posture: Removal of an unused machine-specific
@statamic/cms npm dev dependency reduces install fragility on CI and other developers' machines (no local-path assumptions). Relevant if you have strict build reproducibility or SBOM requirements.
- Feature roadmap signal: No new user-facing capability. Do not plan launch content, demos, or pricing changes around 2.2.1 — treat it strictly as a maintenance release.
When to Consider This Package
Adopt when:
- You run Statamic 5.73+ or Statamic 6 and need asset-container blueprint interaction in the control panel — without 2.2.1 this path is broken.
- You maintain a mixed-version fleet (some sites on older Statamic 5, some on 5.73+/6). The dual route-name resolution means one package constraint covers all of them, avoiding version-pinned forks.
- You want a small, single-purpose addon whose failure mode is well-understood and whose maintainer responds to core-breaking changes.
- Your CI enforces clean installs without machine-specific paths — the removed npm dependency helps here.
Look elsewhere or defer when:
- You are on Statamic 4 or earlier — the compatibility work here is aimed at 5.x/6, and no evidence of support below that.
- You need blueprint editing beyond asset containers (entries, taxonomies, globals) — this is a scoped fieldtype, not a general blueprint management UI.
- You require vendor-backed SLAs or a formal release cadence. This is a small addon with point releases driven by upstream breakage; the 2.2.1 timing shows reactive, not scheduled, maintenance.
- You would be the only consumer of the route-resolution behavior — in that case, a few lines in your own service provider may be cheaper than a dependency, though you inherit the upkeep.
- You cannot accept patch-level upgrade churn during a Statamic upgrade window — coordinate the addon bump with the CMS bump rather than independently.
How to Pitch It (Stakeholders)
For executives: This is a small maintenance release for a Statamic addon, and it matters because it unblocks our Statamic 5.73+/6 upgrade path. Before 2.2.1, one control-panel screen failed outright on the newer Statamic versions. With the fix, the same addon works across our older and newer sites, so we avoid maintaining a private fork or delaying the CMS upgrade. No new features, no migration work, no user-visible changes — low risk, clear upside for upgrade timing.
For engineering: Version 2.2.1 fixes a hard failure introduced by Statamic 5.73 renaming the asset-container blueprint route in the control panel (statamic.cp.blueprints.asset-containers.edit). The fieldtype now resolves whichever route name is registered, so a single release covers older Statamic 5, 5.73+, and 6 — no conditional version constraints needed. It also drops an unused, machine-specific @statamic/cms npm dependency, which cleans up local and CI installs. Action: bump the addon constraint alongside the Statamic upgrade, spot-check the asset-container blueprint screen in the CP after deploy, and re-run a clean composer install + front-end build to confirm the dependency removal is benign. No API or config changes, no data migration, no breaking changes — a patch-level upgrade.