Product Decisions This Supports
- Admin/back-office delivery: Enum-backed fields (status, tier, type, category) render as labeled selects or badges in Laravel Nova, so internal CRUD screens ship without bespoke Blade/field work.
- Build vs buy for internal tooling: Substitutes for a custom Nova field — typically 0.5–2 dev-days to write plus ongoing ownership — with a dependency you can trial in an afternoon. The honest comparison is "small dependency we don't control" vs "small code we do."
- Roadmap sequencing: Admin UX polish is chronically a filler item. This lets it slot into spare capacity instead of competing with customer-facing work for a sprint.
- Domain-modeling direction: Encourages PHP 8.1 native enums as the single source of truth for status vocabularies, with labels living next to the enum rather than duplicated in UI code. Small vote, but it compounds.
- Ops/support quality: Consistent label rendering across screens reduces "wrong status shown" confusion and the tickets that follow.
- Representative use cases: internal ops dashboards, moderation queues, order/subscription state management, content workflow and approval states, feature-flag administration.
When to Consider This Package
Consider it when:
- You already run Laravel Nova — without it, this package is irrelevant.
- Models use PHP 8.1+ backed enums and you want them surfaced with human-readable labels rather than raw values.
- The surface is internal and low-blast-radius: a rendering bug is an annoyance, not a revenue event.
- You need it now and can accept a micro-dependency with a pinned version and a stated fallback.
Look elsewhere or hold when:
- Adoption signals are thin. Zero stars, zero dependents, no visible maintenance activity. Treat as unvetted until someone has actually read the source.
- No tests, changelog, or tagged releases. That is a maintenance-risk signal, not a code-quality verdict — but it belongs in the risk register.
- Compliance or security review requires provenance: license clarity, maintainer identity, CVE response path, SBOM entry.
- Nova version mismatch risk. Nova 4 and 5 field APIs differ; verify compatibility rather than assume it.
- The field is trivial for you. A ~100-line custom Nova field is often cheaper than owning a bus-factor-one dependency.
- You need more than display: cascading/dependent enums, enum arrays or multi-select, enum-driven filters and metrics — likely out of scope.
- You cannot vendor or fork it. Given these adoption numbers, forking is the realistic long-term plan; if policy forbids it, don't start.
Pre-adoption checklist: read the source (it's small), confirm Nova and PHP version support, spike it against one real enum, pin the version in Composer, add it to the dependency-review list, and decide up front who forks it if it goes stale.
How to Pitch It (Stakeholders)
For executives: This is a small, free UI component for our admin panel. It replaces a few developer-days of custom work and makes internal screens more consistent, which reduces operator error and support load. Direct cost is effectively zero. The real consideration is maintenance: the package has very low adoption, so we treat it as a convenience, not infrastructure — pinned, source-reviewed, and replaceable in under a day. Recommendation: approve as a scoped internal-tooling dependency, not a platform standard.
For engineering: A Nova field that maps PHP enums to labeled form controls; tiny surface area. Proposal: pilot on one screen, read the source before merging, pin the version, and keep usage isolated so a fork or an in-house replacement is a drop-in if it goes unmaintained. Don't abstract it into a shared "enum layer" until a second use case appears. Success criteria: ops can read and set statuses without ambiguity, and one item leaves the admin backlog.