khalin/nova4-indicator-field
A Laravel Nova 4 field for displaying compact status indicators in resource tables and detail views. Render colored dots, labels, and conditional states with a simple API—handy for showing boolean flags, health checks, or workflow status at a glance.
Architecture fit. This is a presentation-only Nova field: one PHP field class plus a Vue component that maps a model value to a colored dot, optionally with a label and tooltip. It sits on top of Nova's existing Field contract and composes with standard methods (resolveUsing, exceptOnForms, canSee), so it slots into a resource's fields() array without any new infrastructure — no migration, no config file, no publish step, no separate front-end build in our app. That is the entire architectural footprint, and it is the reason the opportunity score is meaningful despite a 0.45 quality score: the capability is cheap and useful; the package is the risk.
Integration feasibility. The surface is small enough to audit in under an hour and reimplement in about a day. But four gates must be cleared before any adoption decision:
khalin/nova4-indicator-field while the repository lives under oleghalin/nova4-indicator-field. That mismatch must be resolved — who controls Packagist publish credentials — before its compiled JavaScript runs inside an authenticated admin panel. Confirm resolution with composer show khalin/nova4-indicator-field --all.dist/; if not, composer require alone will 404 assets after deploy and require an npm build against laravel-nova in CI.Nova::script() / Nova::style() explicitly. Read the source; do not trust the README.resources/js/ carries Vue 2 residue (new Vue(), filters, $listeners), treat the package as a reference implementation, not a dependency.Also verify the exact color-method name (options() per examples) and the accepted color vocabulary — green/amber/red/gray, not arbitrary Tailwind tokens like emerald-500, which fail silently.
Technical risk. The dominant risks are maintenance and coupling, not code complexity:
Nova.mix() pipeline, the laravel-nova dev dependency. A Nova patch release is the most likely breaker, and the failure mode is a broken admin page, not graceful degradation. A composer constraint conflict could block a Nova security upgrade later.v-html on user-influenced values; if present on interpolated model data, that column is an attack vector against our admins.Key questions to resolve before a build/buy call:
composer show actually resolve, and does the laravel/nova constraint match our lock?dist/, and is there an auto-discovered service provider?Decision framing: the UX increment (scan-a-hundred-rows triage without opening records) is real and cheap. The dependency is not worth taking long-term. Recommendation: fork / reference — vendor the source under app/Nova/Fields/ with MIT attribution.
Stack fit. Laravel + Nova 4 admin surface, no new infrastructure, no warehouse or BI change, no new front-end surface. If dist/ ships, there is zero front-end setup in our app; if not, we pick up an npm build step — a small but real operational tax that argues for vendoring early.
Migration path (two-track).
artisan serve) to validate asset delivery. Cap this at a day."khalin/nova4-indicator-field": "1.0.3"), commit composer.lock, and add a line to the Nova upgrade runbook: re-validate this field on every Nova minor bump.Compatibility. Nova 4.x only; nothing indicates validation past 4.x. Pin Nova itself to a minor range, clear caches after any asset-registration change (config:clear + nova:publish), and decide the Nova 5 posture now — porting this after it is live across a dozen resources is the expensive version of the same decision.
Sequencing.
dist/ presence, provider discovery, color vocabulary, v-html grep).vendor/ — one hour, before writing resource code.StatusIndicator factory used across index, detail, and lenses; normalize enums/nullables with resolveUsing; define an explicit gray fallback for unmapped values; exceptOnForms().withCount in indexQuery before rollout.Maintenance. Ownership effectively transfers to us on day one. Upstream has no cadence, no visible tests, and a single maintainer; the repo/package name mismatch is a supply-chain question that needs answering regardless. Vendoring converts an open-ended dependency risk into a bounded, known code asset we control. Add one runbook line for Nova upgrades either way.
Support. There is no support path and no security-disclosure process. That is acceptable for a read-only presentational field we have audited, and unacceptable for anything we intend to run unexamined. Treat the audit as a one-time cost, not an ongoing relationship.
Scaling. Per-record rendering is cheap; per-record queries are not. Every index row evaluates the field, so any relation or aggregate behind the dot must be eager-loaded or computed in indexQuery — otherwise a colored dot silently becomes an N+1 on the page ops teams refresh most. If the number is genuinely expensive, compute it in a Nova metric with caching and present it elsewhere; do not let a display field drive query cost.
Failure modes (all admin-page-level, none graceful):
dist/ missing or stale → empty or unstyled cells after deploy; reads as a broken package when it is a cache/manifest issue.v-html on user-influenced data → XSS against privileged admins.Mitigations are straightforward and cheap: pin Nova, commit the lock, define the fallback, grep for v-html, vendor the source, and add a visual check to the release checklist for any page using the field.
Ramp-up. Near zero for support and ops users — the change is visual and self-evident (colored dots versus reading text cells). Near zero for engineers already writing Nova fields; about a day for one who is not. The real ramp-up cost is organizational: adopting this forces an early, useful decision on one canonical vocabulary for "amber," "red," and "gray" across resources, lenses, and detail views. Make that decision in step 5, not after the third resource copies a slightly different map.
How can I help you explore Laravel packages today?