Product Decisions This Supports
- Build vs. buy vs. borrow — resolved toward "borrow the pattern, not the dependency." The underlying problem (browser and CDN caches serving stale Nova tool/card/field assets after a deploy) is real but narrow, and it is already solved by framework-native mechanisms (Vite/Mix manifest hashing, query-string cache busting). This package should inform a decision to standardize on the framework path, not a decision to adopt a library.
- Dependency governance / supply-chain policy. With 4 stars, 0 dependents, an archived flag, and a final release in December 2024, this is a useful worked example for a "minimum viable dependency" checklist: no maintainer, no downstream validation, no future security patches. It supports codifying a rule that archived packages require an explicit fork owner and exit plan.
- Technical debt triage. If this package appears anywhere in an existing Nova codebase, that is an actionable finding for the platform team — not a feature request. It should be logged as a maintenance risk with a "replace or fork" ticket, prioritized by how critical the affected admin surface is.
- Deployment and release-process roadmap input. Recurring "hard refresh fixes it" reports from internal Nova users are a signal to invest in asset pipeline hygiene (hashed filenames, cache headers, CDN invalidation on release) rather than per-tool workarounds. This package is evidence the workaround pattern exists; the roadmap item is the pipeline fix.
- Not a roadmap item, not a differentiator. Nothing here changes the customer-facing product. Do not allocate discovery or design time to it beyond the dependency-hygiene decisions above.
When to Consider This Package
Consider it only in these constrained situations:
- You are on a legacy Laravel Nova version (pre-Vite asset pipeline) with an active, reproducible stale-asset bug, and you need a stopgap this sprint. Because it is MIT and archived, treat it as a fork candidate, not a Composer dependency — vendor the code, pin it, and assign an owner.
- You want a reference implementation to read before writing 30 lines of your own versioning logic. Reading is free; depending is not.
- You are doing post-mortem or architecture research on how the Nova ecosystem has handled cache busting.
Look elsewhere — decisively — when:
- The project is new or greenfield. There is no reason to onboard an archived package with zero dependents.
- You are on a modern Nova release with Vite. Content-hashed filenames in the build manifest already solve cache busting; adding a versioning layer is redundant complexity.
- You need maintenance, security response, or compatibility guarantees. Archived means no patches, no Nova major-version support, no CVE response. That is a hard blocker for anything customer-facing or long-lived.
- Your team lacks PHP capacity to own a fork. Taking on an archived package without a fork owner is how a one-line fix becomes a quarterly fire drill.
- The README's listed maintained alternatives satisfy the requirement — evaluate those first; that is the author's own recommendation and should carry weight.
How to Pitch It (Stakeholders)
To executives (one paragraph): We evaluated a small open-source add-on for our Laravel admin panel that fixes a caching annoyance — stale scripts after a deployment. The package is archived, has effectively no user base, and receives no updates, so adopting it would trade a minor inconvenience for a permanent maintenance and security liability. The underlying problem is already addressed by the standard build tooling we use, so our recommendation is to close this out with no spend and no dependency added, and to use it only as a reference if the issue resurfaces.
To engineering (the ask): Do not add norman-huth/nova-assets-versioning to composer.json. If a stale-asset issue is confirmed on a legacy Nova install, either (a) fix it at the pipeline level with hashed asset filenames and correct cache headers, or (b) fork the MIT-licensed code into our own namespace with a named owner. If the package is already in a codebase, raise a ticket to remove or replace it and note the risk in the dependency register.
Framing to avoid: do not present this as a "rejected feature." It is a rejected dependency — the capability stays, sourced from tooling we already own. That distinction keeps the conversation about risk and ownership rather than about saying no to a fix.