wesselperik/nova-status-field
A Laravel Nova field for displaying statuses as colorful labels or badges in index and detail views. Define custom status labels and colors, then drop the field into any Nova resource for a clean, readable status display.
Architecture fit. A single-purpose Laravel Nova field that lives entirely in the admin panel's presentation layer. It maps a model attribute to a label, icon, and color and renders a badge in Nova index tables and detail views. There is no meaningful service provider, no migration, no queue, no storage, no external call — so the only architectural surface it touches is the fields() array of existing Nova resources. That is the ideal shape for a TPM to sponsor: additive, reversible, and it retires a recurring "hand-roll a badge field" line item from the internal-tooling backlog. It is a hard no outside Nova. The attached third-party assessments describe Filament popups and per-icon tooltips, which do not match this repository; treat that documentation drift as a defect in our own package catalog, not just a quirk of this vendor.
Integration feasibility. High for a Nova shop. Composer install, add StatusField::make('Status') to a resource, supply labels() / icons() / colors(), and optionally background() / textColor() as of 3.1.0. The 3.1.0 changes are additive and configuration-level — single value or per-icon mapping, Tailwind tokens or raw colors. The one genuine compatibility edge is the "proper return types" tightening in StatusField.php: any local subclass, decorator, or test double fails at signature level. Most consuming apps carry zero subclasses, so this lands as a CI finding rather than a production outage — but it must be checked before the upgrade merges, not after.
Technical risk. Low-to-moderate, and the risk is vendor profile rather than code. Signals: ~30 stars, 0 dependents, a single maintainer, and a last-release date of 2026-07-06 — a future-dated artifact telling us some metadata in the chain is untrustworthy. Practically, we would be the first serious adopter and cannot lean on an ecosystem to catch breakage. Compounding factors: Nova is a paid, versioned product whose field APIs shift across majors; Tailwind token colors silently no-op if the classes are purged from the compiled bundle; per-icon map key mismatches fail quietly. None are outage-class; all are support-ticket-class. Exposure is capped by pinning the version and keeping the field off customer-facing surfaces.
Key questions.
background() / textColor() are never called, i.e. is backward compatibility real?Stack fit. Laravel + Nova + a Tailwind-compiled admin stylesheet. The field cleanly occupies the "config-driven presentation" slot and replaces one-off Blade partials and bespoke Vue fields. If the organization has standardized on Filament or hand-rolled admin screens, this delivers nothing and should be rejected at intake rather than evaluated.
Migration path. A routine minor bump from 3.0.x: update the constraint, composer update, run the suite. Two guards before merging. First, grep for subclasses, overrides, and mocks of StatusField and fix signatures against the tightened return types. Second, re-verify rendered badges after any Tailwind content-path or safelist change, because token-based colors depend on the class surviving the build. No data migration and no config republication is indicated.
Compatibility. Backward compatible for consumers using the field as published. With zero dependents we have no crowd-sourced evidence of which Nova/PHP/Tailwind combination is exercised in the wild, so budget a short spike against our exact versions rather than trusting release notes. Pin the version — exact or a tight caret — at the same time, so future churn cannot arrive unannounced.
Sequencing.
StatusPalette helper so every resource shares one palette.OrderStatusColumn::make()) that applies the full mapping; reuse it across index, detail, and relation-manager tables.Maintenance. Near-zero runtime maintenance: no jobs, no migrations, no external services, no added queries. The recurring cost is design-system drift — keeping the centralized palette aligned with Tailwind tokens and re-checking contrast when brand colors change. Vendor management is cheap but must actually be scheduled: a single maintainer's minor release can carry a signature change.
Support. Small, concentrated, and predictable. Expect repeat questions on which color formats are accepted (Tailwind token versus raw hex), why a token silently renders as the default, and why a status shows an unstyled badge (map key mismatch or purged class). A one-page internal note plus the reusable factory helper eliminates most of that volume before it forms.
Scaling. No scaling implications. Rendering is per-row and stateless — no cache, queue, or query footprint, and a large status enum adds negligible overhead. The real scaling dimension is organizational: value grows linearly with the number of Nova resources displaying statuses, which steadily strengthens the build-versus-buy case against hand-rolled badges. That is the argument to make when renewing the dependency.
Failure modes. (1) Fatal errors from return-type mismatches in subclasses or test doubles — the only outage-class risk, and it surfaces in CI. (2) Silently unstyled badges from unmapped keys or purged Tailwind classes. (3) Dark-mode contrast failures when background() and textColor() are set independently. (4) Abandonment — with ~30 stars and zero dependents there is no ecosystem forcing function on the maintainer, so vendor or fork if the field becomes load-bearing. (5) Metadata and documentation drift, already evidenced by Filament-oriented assessments attached to a Nova package; that one is ours to fix in the catalog.
Ramp-up. Under an hour for a developer who already knows Nova and Tailwind: read the README color examples, copy the centralized palette helper, done. The genuine onboarding cost is Nova field convention, not this package — which is why the factory helper matters more than the install instructions.
How can I help you explore Laravel packages today?