Nova Assets Versioning Laravel Package

Technical Evaluation

Architecture fit. norman-huth/nova-assets-versioning is a narrow, single-purpose utility for Laravel Nova: it appends version/cache-busting identifiers to Nova custom tool, card, and field asset URLs so browsers and CDNs pick up rebuilt JS/CSS after a deploy. Architecturally this is the right shape for the problem — it sits at the edge of the asset pipeline via a service provider and touches nothing in the domain layer. Coupling is minimal, blast radius is small, and it does not alter application data or request handling. If a team is hitting "Nova tool shows stale bundle after deploy," this is a legitimate category of solution.

Integration feasibility. Install is a standard Composer require with Laravel package auto-discovery; expected effort is under a day including verification. However, feasibility is constrained less by the code than by the package's status: it is archived, unmaintained, 4 stars, 0 dependents, and scored 0.075. Those are strong negative signals on community vetting — effectively no third party has validated it in production at scale. MIT licensing means we can fork and own it, which is the only viable path if the functionality is genuinely needed.

Technical risk. Rated high, concentrated in lifecycle rather than runtime:

Key questions to resolve before any decision:

1. Does it override Nova's asset registration or merely publish/post-process compiled assets? The former is far more upgrade-fragile than the latter.
2. Is the version token a content hash, a build timestamp, or a manual config value? Timestamp-based busting destroys cache efficiency across every deploy; content hashing does not.
3. What Laravel/Nova version constraints are declared in composer.json, and do they resolve against our current matrix?
4. Which maintained alternatives does the README point to, and do they cover our exact Nova version?
5. Can we solve this in-house in under a day (e.g., a Nova::script() wrapper appending ?v=filemtime(...)), making the dependency unnecessary?

Recommendation: Do not adopt as a dependency. Treat as a reference implementation — read the source (it is small), extract the technique, and either build the ~50-line in-house equivalent or adopt the maintained alternative the README names. The opportunity score (26.83) is not high enough to justify carrying an unmaintained package through the next Nova upgrade.

Integration Approach

Stack fit. Targets Laravel + Laravel Nova 4.x era. Confirm the declared PHP and laravel/nova constraints resolve against our pinned versions before spending any time on it; a mismatch here ends the evaluation immediately.

Migration path. Two distinct scenarios:

• Not yet adopted (expected): skip direct install. Implement the pattern in-house behind a first-party service provider or a small Blade/asset helper, so behavior is owned and testable. Cost is measured in hours, not sprints.
• Already adopted somewhere in the estate: pin the exact current version in composer.json, audit what it registers, and schedule removal alongside the next Nova upgrade rather than as an emergency.

Compatibility. The critical compatibility axis is Nova, not Laravel. Nova's asset registration API has changed across majors, and an archived package cannot follow. Verify by running the package against our Nova version in a staging branch with a deliberately stale asset bundle and confirming the URL token changes post-deploy.

Sequencing.

1. Week 0 — Triage: read source, confirm mechanism (hash vs. timestamp), check composer.json constraints, read README alternatives list.
2. Week 1 — Decide: in-house helper vs. maintained alternative vs. do nothing (if our deploy pipeline already busts Nova asset caches via CDN invalidation or filename hashing at build time, this may be a non-problem).
3. Week 2 — Implement & verify: if building in-house, ship behind a feature flag, validate in staging with a real stale-cache scenario, then enable.
4. Ongoing: if forked, vendor it into an internal namespace, add it to the dependency-review roster, and add a check to the Nova upgrade runbook.

Under no circumstances should this be added as an unpinned transitive dependency or left in a "we'll fix it later" state.

Operational Impact

Maintenance. Effectively zero upstream maintenance. Any fork becomes our code: assign a named owner, add it to the internal package registry, and include a test that fails when the Nova version bumps unexpectedly. Budget a few hours per Nova major upgrade to re-verify — small, but non-zero and permanent.

Support. No vendor, no maintainer, no issue triage. Internal support falls to whoever owns the Nova frontend. Escalation path is "read the source," which is feasible here only because the codebase is small; that property should not be assumed for other archived packages.

Scaling. Runtime cost is negligible — string manipulation on a handful of asset URLs at render/registration time. The real scaling consideration is cache efficiency: if versioning is timestamp-based, every deploy invalidates every Nova asset for every user, which on a high-traffic admin surface causes a measurable cold-cache stampede against the CDN/origin. Content-hash versioning avoids this. Validate which strategy applies before rollout.

Failure modes.

• Silent staleness — token fails to change, users run old bundles; hardest to detect because nothing errors.
• Hard 404s — versioned filename points at an asset the publish step didn't emit, breaking the Nova UI entirely.
• Upgrade-time breakage — Nova minor/major release changes the asset API; package fails open (assets unversioned) or closed (UI broken), with no upstream fix coming.
• CDN/edge divergence — edge caches keyed differently from origin, producing per-user inconsistency that is painful to reproduce. Mitigation for all four: an automated post-deploy smoke check that asserts the asset token changed and the URL returns 200.

Ramp-up. Very low for an engineer — a mid-level Laravel developer can read the full source and understand the mechanism in under an hour. The ramp-up cost that matters is organizational: documenting why we own a fork, so the next engineer doesn't re-evaluate this package from scratch. Capture the decision in an ADR referencing the archived status and the chosen alternative.

Bottom line for planning: this is a small, correct-shaped utility that has been abandoned. It represents near-zero adoption risk only if we never take a dependency on it. The right TPM move is to close it out as "reference only," capture the technique in-house, and spend the saved maintenance budget on the Nova upgrade path.