Duration Laravel Package

Technical Evaluation

Evidence basis: This assessment is derived from a single-line release note ("Upgrade to Nova 4") and a public changelog with no prior assessment on file. It is directionally reliable because a Nova major-version bump is a known, well-defined class of change, but the package's own name, scope, and version history are unconfirmed. Treat the below as conditional and validate against the package's composer.json and upgrade guide before committing roadmap.

Architecture fit. The change is a dependency-floor move, not an architectural one. A Laravel package that constrains to Nova 4 is signalling that its admin-UI surface (tools, cards, fields, filters, resource tooling) targets Nova's Vue 3 generation. That is the correct direction for any package still maintained against current Nova, and it aligns with a modern Laravel baseline (PHP 8.0+, Laravel 8+). The architectural question is whether this package is a thin Nova extension — in which case fit is high and the blast radius is the admin panel only — or whether Nova types leak into domain code, in which case an upgrade becomes a cross-cutting refactor.

Integration feasibility. Feasible but conditional on three things: (1) whether we are on Nova 3 today, (2) whether our own custom Nova tools/cards/fields were written against Nova 3, and (3) whether any other Nova packages in our tree remain pinned to nova ^3.0 or ^4.0 incompatibly. Nova 4's frontend rewrite in Vue 3 is the main source of friction — third-party Nova components that have not shipped a Vue 3 build are hard blockers, not soft warnings. Composer will surface the constraint conflicts early, which is the good news; the bad news is that composer resolution failures are the cheap part of the work.

Technical risk. Medium-to-high, concentrated in custom UI and not in the package itself.

The dominant risk is not "does this package work on Nova 4" but "does our Nova 4 estate work at all." A package upgrade can be the trigger for a platform migration we did not scope.

Key questions.

• What is the package's support window — does v1.0.0 drop Nova 3, or support 3 and 4 concurrently? This single fact determines whether the upgrade is optional or forced.
• Is there a v0.x → v1.0.0 API break of the package's own public surface, independent of Nova?
• Which Nova 4 minor does it require, and what PHP/Laravel floor does that impose on us?
• How many of our Nova-adjacent packages and custom components are still on the Vue 2 toolchain?
• Is the "v1.0.0" label a genuine API-stability commitment or a first tagged release?

Integration Approach

Stack fit. Clean if we are already on PHP 8+ and Laravel 8+, which most maintained applications are. The constraint that matters is the transitive one: Nova 4 pulls a modern Laravel floor, and if any of our other packages lag, composer will deadlock. Run a dependency audit (composer outdated, composer why-not laravel/nova ^4.0) before anything else — it converts an unknown into a scoped list in under an hour.

Migration path. There is no incremental path for Nova itself: it is a major-version swap, effectively all-or-nothing at the composer level. The package upgrade should ride along with the Nova 4 migration, not lead it. Recommended shape: branch → bump Nova to ^4.0 → bump this package to ^1.0 → resolve conflicts → rebuild Nova assets via the Nova 4 mix toolchain → smoke-test → merge. Attempting to land this package against Nova 3 is not a supported state and should be rejected outright.

Compatibility. Three layers to verify separately, because they fail differently:

1. Composer layer — version constraints resolve (fast, deterministic, catches most blockers).
2. Build layer — Nova assets compile under the Vue 3 toolchain (nova.mix.js replaces prior mix conventions; laravel-nova npm package must be on the v4 line). Fails loudly at build time.
3. Runtime layer — resources, tools, cards, filters, menus, and asset registration behave. Several Nova 4 API changes (menu builder, asset registration helpers, service-provider boot conventions) are deprecation-style and fail quietly in the admin UI. This layer needs an explicit manual test pass, not a green build.

Sequencing.

1. Dependency audit and blocker inventory (unscoped, ~1 day).
2. Confirm package support policy — does it drop Nova 3? Decide go/no-go.
3. Dedicated migration branch; Nova 4 first, package second, custom components third.
4. Remediate in-house Nova customisations (the long pole — size it before committing a date).
5. Full admin-panel regression pass with a written checklist of every tool, card, filter, and action.
6. Staged rollout behind a feature flag or to an internal-only environment before production.

Operational Impact

Maintenance. Positive if we standardise: staying current with Nova removes an accumulating upgrade debt rather than adding one. The cost is a one-time migration spike plus an ongoing obligation to track Nova 4.x minors. The real maintenance signal to watch is release cadence — a single "Upgrade to Nova 4" commit with no follow-up is a warning sign about future responsiveness.

Support. Two support surfaces now exist: the package vendor and Nova itself (a paid, licensed product). Any admin-panel incident requires triage across both, and vendor support for Nova is licence-tier dependent — confirm our licence tier covers the Laravel/PHP versions we intend to run. Document internally which layer owns which class of bug, or incident response will stall on "is this Nova or is this the package?"

Scaling. Effectively neutral. Nova is an admin surface, not a request-path component; this upgrade does not change application throughput, queue behaviour, or database load. The scaling concern is team scaling, not system scaling: every additional Nova customisation in our estate multiplies the next major-version migration. Cap bespoke Nova UI where a plain resource or filter will do.

Failure modes. Ranked by how they present:

• Install-time conflict — loud, cheap, most likely. Blocked by another ^3.0 constraint.
• Build failure — loud, cheap. Vue 2 syntax or stale laravel-nova npm version.
• Silent admin degradation — quiet, expensive. A tool renders blank, a card 404s its endpoint, a menu item vanishes. No test suite catches this; only manual enumeration does.
• Partial-estate drift — some environments on Nova 3, some on 4, config cached inconsistently. Prevented by pinning and by not running mixed versions across staging and production.
• Abandonment — package goes quiet, we are stranded on a Nova major with no upgrade path and are forced into a fork or replacement.

Ramp-up. Low for developers already fluent in Nova 4 and Vue 3; high for anyone whose only Nova experience is the v3 toolchain, because the component model, build tooling, and asset registration idioms all shift. Budget a half-day of orientation per engineer on the Nova 4 upgrade guide before they touch custom components — that half-day reliably saves more than it costs in misdirected porting work. The package itself needs no ramp-up; it is a version constraint, not a new concept.

Recommendation. Do not adopt v1.0.0 as a standalone change. Bundle it into a scoped Nova 4 migration, gated on the dependency audit and a written inventory of our custom Nova components. If the audit shows we are already on Nova 4, this release is a low-risk, adopt-on-sight patch. If it shows we are on Nova 3 with substantial bespoke tooling, treat it as a minor platform project with its own estimate — and resolve the "does it drop Nova 3 support?" question before that estimate is written.