Ux Cropperjs Laravel Package

Product Decisions This Supports

• Build vs. buy for image-cropping UX. This package (Symfony UX Cropper.js) gives you a maintained Stimulus controller plus Twig/form integration around Cropper.js. For any feature that needs "upload a photo, frame it, save it," the default PM answer should be adopt a package, not build a cropper from scratch — the build option historically costs 1–2 sprints of front-end work plus ongoing browser-compat upkeep.
• Roadmap input for image-centric features: profile avatars, product/gallery images, banner and thumbnail framing, KYC/ID document trimming, marketplace listing photos, CMS media library. These are typically "table stakes" items that get deferred; a low-cost dependency moves them from "nice to have" to shippable.
• Platform-upgrade decisions. v3.6.0's fix (#3919) removes a conflict between this package and symfony/asset-mapper 8.2+. If our Symfony stack is on or moving to AssetMapper 8.2+, v3.5.0 was a latent blocker for this feature area. That is a "can we upgrade the platform without regressing media uploads" question, which is a PM-visible risk, now cleared.
• Use-case scoping. The package covers client-side crop with aspect-ratio presets and output as a data/blob payload for server-side persistence. That fits "user frames their own image." It does not fit automated server-side cropping/normalization pipelines (see below) — that distinction should be settled before committing to a design.
• Dependency-risk accounting. The v3.6.0 delta is tooling deps, a README placeholder fix, and one compatibility bug fix. No API surface change, no deprecations, no breaking changes. From a PM standpoint this is a maintenance-health signal, not a reason to re-plan work: the package is still receiving fixes and stays inside Symfony's semver/BC policy.

When to Consider This Package

Adopt when all of the following hold:

• The product is Symfony-based (Symfony 6.4/7.x+, PHP 8.x), with Twig forms and either Webpack Encore or AssetMapper. This is a Symfony UX package, not a Laravel one — despite the general "PHP package" framing, a Laravel-first codebase should evaluate Cropper.js directly or a Laravel/Inertia-specific integration instead.
• The front end is server-rendered Twig + Stimulus, and the team values no custom JS build step (AssetMapper path) or already uses Symfony UX elsewhere.
• The requirement is interactive user-driven cropping with fixed or user-selectable aspect ratios — not generative or AI-driven framing.
• You want MIT-licensed, Symfony-org-maintained code rather than an in-house controller.

Look elsewhere when:

• Laravel or non-Symfony PHP — the form/Twig/AssetMapper integration is where the value lives; without it you are just importing Cropper.js.
• SPA/React/Vue front ends — use a native JS cropper component; the Symfony glue adds a layer without benefit.
• Server-side or batch cropping is the actual need (thumbnails, format conversion, CDN variants) — that's Intervention Image / Glide / Cloudinary territory. This package is the input UI, not the processing pipeline.
• Heavy digital-asset-management requirements — transformations, focal-point AI, multi-derivative delivery. A SaaS DAM will beat a bundled cropper on total cost.
• Strict no-new-dependency policy or a team unwilling to take a Symfony UX dependency for a single widget — the package is small enough to vendor if needed.

How to Pitch It (Stakeholders)

For executives (30 seconds): We can ship production-quality image cropping — avatars, product photos, listing images — by adopting a small, MIT-licensed component maintained by the Symfony core organization, instead of building and maintaining that UI ourselves. Estimated saving is roughly one to two sprints of front-end effort plus the recurring cost of browser-compat fixes. The just-released v3.6.0 is a maintenance release that also clears a compatibility clash with symfony/asset-mapper 8.2+, so adopting it will not block our platform upgrade path. Risk profile is low: no breaking changes, no new API surface, standard semantic-versioning guarantees.

For engineering: v3.6.0 = tooling-dependency bump, README command-format fix, and one bug fix resolving the symfony/asset-mapper ≥8.2 conflict. Nothing to migrate. The integration surface is a Stimulus controller plus form/Twig wiring; state lives in the DOM and the crop result is handed back as an image payload, so it drops into existing upload flows without touching our storage or validation layers. Caveat to confirm before we commit: this is Symfony UX, so if the target surface is a Laravel service we should instead take Cropper.js directly and skip the Symfony-specific glue. Recommended next step: a timeboxed pilot on one low-risk surface (e.g., avatar upload in account settings) to validate UX and payload handling, then decide on broader rollout.