Product Decisions This Supports
- Ship admin branding without forking Nova. The package is a config-driven asset layer: it points Nova's compiled CSS/JS at our own files, so white-labelling (logo, palette, typography, hidden UI chrome) becomes a sprint-sized deliverable instead of a fork-maintenance project. That defers, by one or more releases, the far more expensive "build our own admin surface" decision.
- Frame build vs. buy on admin UX. It gives us the cheapest rung of a three-rung ladder: customize Nova cosmetically (this package), build first-party Nova tools/cards (real capability), or replace the admin with a SaaS control panel (highest cost and capability). Budget it as time-buying, not capability-buying.
- Gate the Nova 4 → 5 roadmap epic. v1.2.4 exists solely as a "Nova 5 fix" (PR #41, first-time contributor). Every Nova-major upgrade epic must list this package as a dependency to be re-verified after Nova lands — never before, since it follows Nova's asset layout rather than defining it.
- Enable white-label / multi-tenant admin as an offering. Environment-aware config makes per-brand or per-tenant asset sets feasible from one codebase, which is the strongest product argument for adoption and feeds pricing/packaging decisions for branded admin portals.
- Hold the scope line explicitly. Adopt it as a cosmetic patch layer only. The moment a requirement touches auth, routing, field logic, or data, that is a signal to fund a proper Nova tool — not to stretch this dependency.
- Make a portfolio-level dependency call. Archived repo, MIT, single maintainer, 25 stars, zero dependents, sitting on top of a paid closed-source product. Product should decide this deliberately — vendor it as internal code with a named owner and frozen scope, or decline — rather than inherit the decision from engineering by default.
When to Consider This Package
Consider it when:
- We are on Laravel Nova (Nova 5 supported via v1.2.4) and the requirement is presentational only — branding, colour variables, logos, typography, hiding UI chrome — and Nova's own config doesn't expose it.
- We need those changes to survive
composer update and php artisan nova:publish without a fork or a fragile post-install hack.
- We accept a now-archived, low-bus-factor dependency and mitigate by vendoring the code, pinning exactly (
1.2.4, never ^1.2), and assigning internal ownership.
- We have a licensed Nova sandbox in CI so the change can be smoke-tested. If we can't test it, we shouldn't ship it.
- The change is bounded. This is a patch layer; it turns into technical debt the moment it carries behaviour.
Look elsewhere when:
- We need maintenance guarantees, a security review, or vendor support — none exist upstream; the fix line has formally stopped.
- We are not on Nova, or on a Nova version outside the supported range — the package hooks compiled asset paths and hashes that are not a stable public contract.
- The requirement is anything other than assets: auth, routing, fields, request lifecycle, data.
- The need justifies a first-party Nova tool/card, or an admin replacement — past a certain scope the cheap option stops being cheap.
- Our deployment model can't run the artisan step (immutable/containerized images with
public/vendor gitignored) and engineering can't add it to the image build.
- Legal/Support flags that modifying Nova's published assets conflicts with the Nova licence — confirm before committing.
How to Pitch It (Stakeholders)
To executives: This is a small, free, MIT-licensed add-on that lets us re-skin the Laravel Nova admin panel — logo, colours, UI chrome — through configuration, without forking Nova or rebuilding our admin. It keeps our changes outside vendor/ so they survive composer update, and the v1.2.4 release explicitly addresses Nova 5, which de-risks our upcoming Nova upgrade. Two caveats must be stated up front: the project is archived and single-maintainer (25 stars, zero dependents), and it depends on Nova's internal asset layout, which is not a stable public contract. Recommendation: do not adopt it as a live third-party dependency for new work. If we need the capability, vendor the small amount of code into our own repo so we own it, pin version 1.2.4 exactly, wire the step into the deploy pipeline immediately after nova:publish, and add a half-day of re-verification to every Nova major upgrade.
To engineering: Treat this as build/deploy tooling, not application code — it mutates assets the admin panel needs in order to boot, so blast radius is small but severity is high. v1.2.4 is a Nova 5 compatibility fix from a first-time contributor, which is itself evidence that Nova's asset filenames and hashes shift across majors; with the repo archived, the next Nova major is an unpatched break. Before committing: resolve the identity mismatch (registry entry norman-huth/nova-assets-changer vs. repository/composer namespace Muetze42/...) so we know we're installing the code we audited; read PR #41 and the v1.2.4 composer.json to confirm the declared laravel/nova constraint (does it still admit ^4.x?) and whether the fix is version-guarded or hard-coded; account for the missing v1.2.3 in the changelog gap (v1.2.2 → v1.2.4); spike on a licensed Nova 5 sandbox, run the artisan step twice, then run nova:publish and confirm the admin UI renders and the step is idempotent; add a CI smoke test asserting the login page renders with expected asset hashes and cache-busting updates on deploy; and record an ownership decision if the maintainer stays dark. Budget roughly half a day to install and exercise, one to two days to productionize with CI — the real learning cost is our own asset-publishing conventions, not the package.