Statamic Imagehotspots Laravel Package

Technical Evaluation

Architecture fit: This is a Statamic addon (composer package) that ships a custom fieldtype for asset containers, registered through Statamic's addon service provider and surfaced in the Control Panel. It sits entirely inside the existing Statamic/Laravel application boundary — no new infrastructure, no separate runtime, no data-store changes. Architecturally it is a thin CP-layer extension, which is the lowest-risk category of Laravel package to adopt.

Integration feasibility: High. The release is a compatibility fix, not a feature or schema change. The core change — resolving whichever of the two asset-container blueprint route names exists rather than hardcoding statamic.cp.blueprints.asset-containers.edit — is a defensive lookup pattern applied at the point of route generation. It requires no config migration, no publish-and-tag step, and no consumer-side code changes.

Technical risk: Low but non-zero:

• Route-name coupling (primary risk). The fix binds the addon to Statamic's internal CP route naming. It is tolerant of the two known names but will break again if upstream renames a third time. This is an accepted trade-off versus a hardcoded string, but it should be treated as a recurring maintenance obligation, not a one-time fix.
• Version-spanning support. Claiming simultaneous support for older Statamic 5, 5.73+, and 6 widens the compatibility matrix. Test coverage across those bands is the question, not the fix itself.
• Dependency removal. Dropping the unused @statamic/cms npm dependency is a build-hygiene improvement and removes a machine-specific artifact. Verify no downstream asset build (Vite config, published vendor assets) implicitly relied on that package resolving.

Key questions:

1. Does 2.2.1 have CI matrix coverage for Statamic 5.x pre-5.73, 5.73+, and 6.x, or is the multi-version claim asserted without automated proof?
2. Is the route resolution implemented as an explicit allowlist of known route names, or a broader existence check? The former is predictable; the latter can mask genuine misconfiguration.
3. Are there other hardcoded Statamic CP route names elsewhere in the addon that were missed by this fix?
4. What is the upstream support window for this package relative to Statamic 6 — is a 3.x/Statamic-6-only line planned?
5. Is the npm dependency removal purely internal (author-side build), or did it affect published distributable assets?

Integration Approach

Stack fit: Native. Requires Laravel + Statamic, installed via Composer, registered as a standard Statamic addon. It consumes Statamic's blueprint/fieldtype APIs and CP routing only — no queue, cache, or database surface. Fits the existing application without introducing a parallel abstraction.

Migration path: Patch-level upgrade (2.2.x → 2.2.1). Standard composer update in a feature branch, then verify the asset-container fieldtype renders and its edit link navigates correctly in the CP. No data migration, no republish of assets expected, though a php artisan vendor:publish --force sanity check on any published config/views is cheap insurance. Rollback is a version pin — the change is small and self-contained.

Compatibility: The fix is explicitly additive in effect: environments below Statamic 5.73 keep working via the old route name, 5.73+ works via the new one, and Statamic 6 is covered. This is the ideal shape for a patch — no floor raised, no ceiling lowered. Confirm the addon's declared composer.json constraints actually permit the Statamic 6 install you intend to run, since release notes and constraint declarations can drift.

Sequencing:

1. Land 2.2.1 on a staging/low-traffic environment first; exercise the asset-container blueprint edit path on the current Statamic version to confirm no regression.
2. If a Statamic 6 upgrade is on the roadmap, take 2.2.1 before the Statamic bump — this fix is effectively a prerequisite for that upgrade, and doing it first separates addon failures from platform failures during the upgrade.
3. Remove any local workarounds (patched vendor files, pinned route shims) that teams may have applied to survive the broken route.
4. Only then widen to production.

Operational Impact

Maintenance: Low ongoing load, with one caveat: the package now carries explicit knowledge of Statamic's CP route names. Every Statamic CP refactor becomes a potential silent breakage in this fieldtype. Budget a small, recurring "verify after Statamic minor upgrade" check rather than assuming set-and-forget.

Support: The package handles its own upstream-compat issue responsively (issue #15 → patched release), which is a positive health signal for a small addon. Bus-factor risk remains typical of single-maintainer community packages — a handful of consumers, likely one primary maintainer. Treat it as community-supported, not vendor-supported, and avoid letting it become load-bearing for a critical editorial workflow without a fallback plan.

Scaling: Effectively irrelevant at scale. This is CP-side blueprint tooling; it does not touch request throughput on the delivery tier. Editorial concurrency is bounded by Statamic's own CP limits, not by this addon.

Failure modes:

• Silent route drift. A future Statamic rename produces a "route not defined" exception again, localized to the asset-container fieldtype screen. Impact is editorial-only (CP broken for that fieldtype), not public-facing. Detection depends on editorial QA, not monitoring — worth adding to a post-upgrade smoke test.
• Partial-compatibility false confidence. The multi-version support claim is only as good as its test matrix.
• Asset build drift from the removed npm dependency, if any published assets depended on it.
• Rollback safety. Easy — pin to prior 2.2.x; no data shape changed.

Ramp-up: Near zero for developers already working in Statamic; installing the addon and using the fieldtype is a matter of hours, not days. The only real knowledge cost is the version-compatibility surface: whoever owns the upgrade path should know that <5.73, 5.73+, and 6 are three distinct route-name regimes, so that the next "route not defined" error is diagnosed in minutes rather than rediscovered from scratch.

Assessment: 2.2.1 is a low-risk, clearly-scoped compatibility patch that unblocks Statamic 5.73+ and 6. Adopt it. The only strategic note is that it converts an upstream coupling into a maintenance obligation — cheap, but real, and worth tracking against future Statamic minor releases.