Statamic Image Cropper Laravel Package

Product Decisions This Supports

• CMS upgrade planning (primary): This release exists to unblock Statamic 6. If our roadmap includes a Statamic 6 migration, this is a direct dependency check — the addon restores image cropping / focal-point editing in the control panel on v6.
• Build vs. buy (buy/adopt): Provides editor-facing crop controls that would otherwise be a custom fieldtype or a paid DAM integration. Adoption is cheap; the decision is about which fork to depend on, not whether to build.
• Feature enablement for content teams: Enables editors to set crop regions and focal points without a designer re-exporting assets — a workflow/productivity gain, not a new customer-facing capability.
• Dependency governance: Because this is a fork (v2.0.0 is its first release), there's a real fork-vs-upstream decision: pin upstream v1.7.x, adopt this fork, or maintain internally. That's a maintainership/risk call as much as a technical one.
• Roadmap signal: The maintainer added CI, Larastan static analysis, ESLint, build-output verification, and CLAUDE.md. That's an explicit bet on AI-assisted maintenance — relevant if we're evaluating which community packages to standardize on.

When to Consider This Package

Adopt when:

• You're on Statamic 6 and need crop/focal-point UI on assets — this fork is currently the path forward.
• You're on Statamic 5, blocked from upgrading only by this addon, and can absorb a major-version jump.
• You can pin a Composer constraint and track a single-maintainer package in your dependency review cadence.
• Your editors genuinely need crop presets; bare Statamic focal point + Glide isn't enough.

Look elsewhere (or stay put) when:

• You're on Statamic 4/5 — the 1.7 → 2.0 major bump almost certainly means the older Statamic line is no longer supported. Stay on upstream v1.7.x until your upgrade. Verify the statamic/cms constraint before planning anything.
• You need vendor support, an SLA, or a security-reviewed dependency. This is a community fork with a bus factor of 1.
• Upstream (tv2regionerne/statamic-image-cropper) ships its own Statamic 6 release — prefer upstream to avoid divergence and a permanent fork tax.
• You need real DAM capabilities — renditions, CDN transform pipelines, rights/metadata management. This is a CP editing convenience, not asset infrastructure.
• Your procurement process requires provenance review: the code was implemented with agentic tooling and has had no external audit. CI and static analysis are positive signals, not assurance.

How to Pitch It (Stakeholders)

For executives: A free community add-on that lets our editors crop and focal-point images inside the CMS. The new v2.0.0 is the version that works with Statamic 6 — so it removes one of the blockers to upgrading our CMS, which is where security patches land. Cost is zero and there's no contract. The trade-off is that it's maintained by one volunteer, so we pin the version, keep an internal fork option open, and don't let it become load-bearing infrastructure.

For engineering: Treat this as a breaking upgrade, not a drop-in — v1.7 → v2.0 bundles Statamic 6, Vue 3, and Tailwind 4. Scope it as part of the Statamic 6 migration ticket, not a routine composer update. The fork adds real guardrails the upstream lacked (Larastan across multiple PHP versions, PHPStan deprecation rules, ESLint, CI verification that build output is committed) — that's a meaningful quality step up and lowers our review burden. The flip side: the implementation was AI-assisted, the maintainer is new to the project, and this is release #1. Before production use, do a focused read of the crop/asset-manipulation path, confirm upstream parity (nothing silently dropped in the fork), and check whether upstream intends its own Statamic 6 release — if it does, prefer upstream and revisit this fork only if it stalls. Pin the constraint, and keep the crop field data model in mind so a swap back to upstream isn't a data migration.