Nova Assets Changer Laravel Package

Technical Evaluation

What it is (TPM framing): a config-driven asset overlay for Laravel Nova — swaps/brands Nova's shipped CSS/JS in vendor/laravel/nova/public without forking Nova or editing vendor files. It is a presentation-layer patch, not a capability. The TPM's job is to treat it as a time-buying tool on the roadmap, not as a feature in itself.

Architecture fit. The best case for a TPM: it is a side-car, deploy-time tool with no service, no schema, no request-path surface, and no API. It cleanly defers the much larger "build our own admin surface" decision by one or more releases — the single strongest product argument for it. The counterweight to carry into planning is that it mutates assets the admin panel cannot boot without: small blast radius, high severity, so it must be owned as build/deploy tooling with a named owner, not absorbed silently as application code.

Integration feasibility. composer require + vendor:publish + one artisan step. A Laravel-fluent engineer can spike in under a day. The TPM gate is CI: Nova is a paid, credentialed dependency, so any automated verification requires a licensed Nova install in the pipeline. If we cannot test it in CI, we should not ship it.

Technical risk — the deciding signals for a TPM decision log.

• Archived: yes. Dominant risk and the reframing input. A single-maintainer community package wrapping a paid, closed-source product has formally stopped receiving upstream fixes. For new adoption this is close to disqualifying; for existing installs it means we own this now.
• Coupling to Nova internals. v1.2.4 exists solely as a "Nova 5 fix" (PR #41, first-time contributor) — direct evidence that Nova's compiled asset layout is not a stable public contract. With no maintainer, the next Nova major is an unpatched break.
• Supply-chain identity mismatch. Registry entry norman-huth/nova-assets-changer vs. repository/composer namespace Muetze42/.... Confirm we install the code we audited before anything merges.
• Non-contiguous changelog. v1.2.2 → v1.2.4; v1.2.3 is unaccounted for. Confirm nothing else shipped in the gap.
• Idempotency and drift. Asset-rewriting tools are sensitive to repeated runs and to nova:publish/nova:install overwriting customizations.
• Unvalidated blast radius. 25 stars, zero dependents; opportunity score 21/100 is consistent with a narrow, low-activity utility. No field reports to lean on.
• Nova 4 regression risk. Unknown whether the Nova 5 fix preserves Nova 4 behavior; the package may now be Nova-5-only.

Key questions (for the TPM to close before committing).

1. What laravel/nova constraint does v1.2.4 declare — does it still admit ^4.x?
2. What exactly did PR #41 change, and is it version-guarded or hard-coded to an asset name/path?
3. Does it work on immutable/containerized deploys where public/vendor is gitignored?
4. Are there tests, and can they run without a Nova license?
5. What happens on a second consecutive run, and after nova:publish?
6. What is in the missing v1.2.3?
7. Why was it archived, is the maintainer reachable, is there a successor fork? If not, the only viable adoption is vendor and own.
8. Does Nova's license permit modifying published assets — and does doing so void vendor support?

Integration Approach

Stack fit. Laravel + Nova 5 (this release). Composer-only; the package adds no npm step, but producing replacement assets implies an owning front-end build on our side (Vite/Tailwind). PHP floor follows Nova 5's own requirement — confirm against our runtime.

Compatibility. Pin exactly (muetze42/nova-assets-changer: "1.2.4"), never ^1.2. The v1.2.2→v1.2.4 gap is precisely where a caret range would silently move us across a Nova major. Verify the declared Nova constraint before install and resolve the norman-huth vs Muetze42 naming question first. Treat the version pin as a TPM-enforced planning artifact, not an engineering preference.

Migration path.

• Nova 4 today: no action; stay on the version already in use. v1.2.4 is not a reason to move.
• Planning Nova 4 → 5: sequence Nova first, package second. The package follows Nova's asset layout and cannot be validated ahead of the Nova upgrade. Put it on the upgrade checklist as a dependency inside the Nova epic — not as a post-launch detail.
• No prior adoption: greenfield evaluation — but with the repo archived, build-vs-vendor leads. Default recommendation is not to add a new archived dependency; either vendor the few hundred lines we actually need or implement the asset override directly in our own code.

Sequencing (the TPM's rollout plan).

1. Read + reconcile (~1 hour, no install): PR #41, v1.2.4 composer.json, confirm declared Nova constraint, resolve the naming mismatch.
2. Decide vendor/fork vs. adopt with archive status as the deciding input. Record the decision and named owner in the dependency register.
3. Spike on a licensed Nova 5 sandbox: install, run twice, run nova:publish, screenshot the admin UI. Exit the spike only when re-run behavior is observed, not assumed.
4. CI smoke test asserting the admin login page renders non-empty with expected asset hashes; verify idempotency and cache-busting.
5. Wire into deploy after nova:publish (and in post-autoload-dump) — never by human memory.
6. Roll to staging → production behind the normal release train.

Exit criteria. Documented re-run behavior, a CI check we own, cache-busting verified, and a recorded ownership decision if the maintainer stays dark.

Operational Impact

Maintenance. Low ongoing code cost, but a recurring upgrade tax: every Nova release can change asset filenames/hashes, so it needs re-verification on each Nova bump — budget roughly half a day per Nova upgrade, not per package release. Because the repo is archived, there is no upstream fix line; maintenance becomes ours by default. This is the number to put in front of the roadmap during Nova-major planning.

Support. No SLA, no vendor backing, archived maintainer. Laravel/Nova Support will not assist with a modified Nova asset bundle — customizing published assets is a plausible support-voiding act. Confirm license terms before rollout; either accept the risk formally in writing or keep an internal fork we can patch.

Scaling. No runtime scaling dimension — static assets, unchanged delivery path. The scaling-adjacent concern the TPM owns is caching and multi-tenant fan-out: environment-aware config lets one codebase serve per-brand or per-tenant asset sets, which underpins white-label/branded admin portals as a product offering — but only if cache-busting changes the asset version/hash every deploy. Otherwise CDNs and clients serve stale JS/CSS and the admin panel misbehaves for a subset of users.

Failure modes (for the risk register).

• Blank or partially rendered Nova admin UI after an upgrade — highest severity, near-certain if version pinning slips or a Nova major lands with no maintainer patch. Detection: CI smoke test on the admin login page.
• Silent drift — nova:publish or a manual re-publish overwrites customizations; the panel reverts to stock without an error. Detection: asset-hash assertion in CI, not visual QA.
• Stale assets via CDN — cache-busting missed on deploy; a subset of users see old UI, hard to reproduce. Detection: verify hash changes on deploy, cache-invalidation check.
• Second-run corruption / non-idempotency — repeated runs corrupt or double-apply. Detection: run-twice in spike, captured in runbook.
• Container build failure — public/vendor gitignored, artisan step missed in image build. Detection: deploy-pipeline step ordering, not memory.
• License/support void — Nova vendor disclaims on modified assets. Detection: legal/support sign-off before rollout.

Ramp-up. Learning cost is our own asset-publishing conventions, not the package. Budget roughly half a day to install and exercise, one to two days to productionize with CI. The TPM's leverage is to schedule that half-day inside the Nova-upgrade spike and the productionization inside the sprint that ships branding — not to treat this as a "small add-on" that quietly appears in a release.