Nova Advanced Image Laravel Package

Product Decisions This Supports

• Admin/CMS image workflow scope — decides whether content editors can crop and resize images inside Nova at upload time, or whether that work is pushed to designers, a separate DAM, or a manual asset pipeline. This is the difference between a self-serve editorial workflow and an engineering bottleneck.
• Feature scoping for media-heavy surfaces — supports go/no-go on features that depend on consistent image aspect ratios: hero banners, category tiles, author avatars, product thumbnails, marketing landing pages, OG/social share images. If crop-at-upload is cheap, these become small features; if not, they become "we'll do it in Photoshop for now."
• Build vs. buy on the admin layer — quantifies the engineering cost of a custom Nova field (PHP field class + Vue cropping component + storage/serving rules + Nova upgrade maintenance) against adopting an MIT-licensed package. Typical outcome: adopt or fork rather than build from zero.
• Roadmap sequencing — crop/resize is usually a prerequisite for a self-serve content release, not a headline feature. It is a dependency to clear early in a release train, not something to schedule late.
• Scope boundary for image transformation — clarifies the split between editorial cropping (this package, admin-side, human intent) and derivative generation (server-side responsive variants via Intervention Image / Glide / a CDN). This package does not replace a transformation pipeline; it complements it. Getting that line right prevents an oversized build and prevents 4 MB originals from shipping to production pages.
• Dependency and upgrade planning — adopting a Nova field means tracking Nova major versions. This is an explicit, recurring maintenance line item and a constraint on when the team can upgrade Nova.
• Risk acceptance on a supplier — with 3 stars and 0 dependents, adoption is a small-vendor bet. That is a decision about vendor policy (is a fork-and-own strategy acceptable?), not just a technical choice.

When to Consider This Package

Consider it when:

• The product already runs on Laravel Nova and will continue to. This package has no value outside Nova; Nova is a paid, opinionated dependency, so this is only rational if Nova is a settled decision.
• The immediate need is editor-controlled cropping and resizing inside the admin panel — a defined aspect ratio per field, a cropper in the form, dimensions stored or enforced on save.
• The team is small and a 1–2 day spike is cheaper than a 1–2 week custom field build.
• The requirement is genuinely narrow: one or a few image fields, a handful of editors, no complex asset governance.
• You can pin the version, vendor the code, and read it. MIT license permits forking; a single-maintainer package with this adoption profile should be treated as source you own, not a dependency you trust to evolve.
• Maintenance signals check out in the spike: compatible with your Nova major version, PHP/Laravel versions, and the release cadence. Note that recent releases (v2.3.2 → v2.3.3) are Dependabot-only bumps — automated dependency hygiene, not product evolution. That is a mildly positive maintenance signal (the repo is not abandoned and automated tooling is live), but it is not evidence of a feature roadmap or of Nova-compatibility work. Verify compatibility by reading the source and commit history, not the release list.

Look elsewhere when:

• Not on Nova, or Nova is a candidate for replacement. Do not let a field package become an argument for keeping an admin framework.
• The real requirement is server-side derivative generation — responsive srcset, WebP/AVIF conversion, CDN-backed on-the-fly transforms. Use Intervention Image, Glide, or a media service. This package is not that.
• The requirement is asset governance: rights/licensing metadata, alt-text enforcement at scale, approvals, versioning, focal-point libraries, folder taxonomies, audit trails. That is a DAM decision, not a field decision.
• Compliance or accessibility obligations are in scope. Alt text, captioning, and file validation are first-class requirements here, not extras — confirm they are covered before committing.
• You need community support and a proven upgrade path across Nova majors. With 0 dependents, you are the first person to hit most edge cases, and you will be the one filing the issue.
• The workflow needs multiple renditions per upload managed as a coherent set. Field-level crop packages tend to handle one crop per field; multi-variant needs get awkward fast.

How to Pitch It (Stakeholders)

For executives — the one-paragraph version: This is a small, MIT-licensed add-on that lets our editors crop and resize images directly in the admin panel instead of round-tripping through design or engineering. It removes a routine bottleneck from every content and campaign launch, and it is cheap to trial. The caveat is that it is a young, single-maintainer package with essentially no adoption — the latest release is dependency housekeeping only, which tells us the lights are on but not much about direction. So we treat it as code we take ownership of, not a vendor we rely on. Recommendation: fund a short spike, and if it works, vendor and pin it with an internal owner. Total exposure is small and reversible; the avoided work is a custom admin field plus its ongoing maintenance.

For engineering — the framing they will care about:

• Buy, then own. MIT license; plan to fork or vendor and pin, with a named internal maintainer. Do not take an unpinned dependency on a 3-star, 0-dependent package.
• Verify before committing: Nova major-version compatibility, PHP/Laravel constraints, how crop data is persisted, what happens to originals, whether resizing is client-side only or enforced server-side, and whether alt text and file validation are handled.
• Latest release adds nothing functional. v2.3.3 is two Dependabot PRs: @vue/babel-plugin-jsx 1.5.0 → 2.0.1 (a major bump, but build-time only — it affects how the Vue component is compiled, not runtime behavior) and actions/checkout 5 → 6 (CI only). Confirm the released asset bundle was built and committed from the bumped toolchain before you rely on it; if you fork, you inherit that Node build chain and own it.
• Respect the boundary. This is editorial cropping, not a transformation pipeline. Responsive variants, format conversion, and CDN delivery stay with Intervention Image / Glide / our CDN. If we blur that line, the scope doubles.
• Budget the upgrade tax. Every Nova major upgrade now includes a field-compatibility check. Small, but real, and it belongs in the release plan.
• Exit criteria for the spike: one representative image field working end to end in staging with real editor content, crop data persisted correctly, and a read-through of the source for anything that would block a fork. If any of that fails, build a minimal custom field — the fallback is bounded and known.