Nova Enum Field Laravel Package

Product Decisions This Supports

• Admin tooling roadmap (Nova vs. alternatives). This package only has value inside Laravel Nova, so evaluating it is really a checkpoint in the "do we keep investing in Nova for back-office tooling, or migrate to Filament/custom admin?" decision. v3.3.0 adds Nova 5.x support, which means the package will still be viable through a Nova 5 upgrade — so this stays a cheap UX upgrade if you are committing to Nova for the next 12–18 months. If Nova itself is under review, the decision is unchanged: defer.
• Build vs. buy for enum-backed state fields. The package is a thin field + filter wrapper around PHP 8.2+ native enums (v3.3.0 dropped PHP 8.1). That makes it a genuine build-vs-buy decision with a clear answer: the "build" option (a custom Nova Select field mapping Enum::cases() to labels plus a Filter) is roughly a day of engineering and gives you full control. Buying is justified mainly as a time-saver and a way to avoid re-solving the same problem in each project.
• Consistency of state modeling across the product. Backing statuses, roles, and types with native enums is a product-wide decision. This package supports it by removing the last excuse for storing raw strings in the database — the admin UI will render labels and let ops filter by case, so enums stay the single source of truth from domain layer to admin panel.
• Operational workflow features. Enum filters directly enable triage and reporting workflows: "show me all orders in PendingReview", "list users with Suspended status". This is the kind of feature that reduces support load without a new dashboard.
• Feature scoping for internal tools. Useful for prioritising small admin-experience wins (readable labels, filterable state) versus larger reporting builds — often the cheap fix removes most of the demand for the expensive one.
• Platform upgrade timing. v3.3.0 is a platform-alignment release: Laravel 12.x and Nova 5.x are now supported, Laravel 10.x and PHP 8.1 are dropped. If the team's upgrade train includes Laravel 11/12 or Nova 5 in the next two quarters, this package no longer blocks it — a previously plausible objection ("the admin add-on will hold back the framework upgrade") is now off the table.

When to Consider This Package

Adopt it when all of the following hold:

• You are already running Laravel Nova (the licence cost and framework lock-in are sunk). v3.3.0 supports Nova 5.x; Nova 4 compatibility is not stated in the release notes, so confirm on your pinned version before upgrading.
• Your domain models use PHP 8.2+ backed enums for statuses/roles/types, not constants or lookup tables. v3.3.0 dropped PHP 8.1 — if any service in scope is still on 8.1, the previous release is the last one you can use.
• Your application is on Laravel 11.x or 12.x. Laravel 10.x support was dropped in v3.3.0; Laravel 10 shops must pin to the prior major line.
• Admin users need to filter or scan by enum state regularly — i.e. the enum is an operational dimension, not just a technical detail.
• You want human-readable labels in the Nova UI without hand-writing a custom field per enum.
• You are comfortable treating the dependency as vendored code: still a small package with a single maintainer and limited dependents, so bus-factor risk is real. MIT licensing and a small surface area make forking or inlining cheap, so plan for that from day one. The v3.3.0 release is a mild positive signal on maintenance — the maintainer is tracking upstream framework and Nova releases rather than letting the package rot.

Look elsewhere (or build in-house) when:

• You are not on Nova — this is not portable to Filament, Livewire tables, or custom admin panels.
• You are pinned to Laravel 10.x or PHP 8.1 in the near term; adopting means either an unrelated platform upgrade or pinning to an older, now-unsupported release line.
• You need behaviour beyond a select field and a filter: dependent/cascading enums, multi-select enum sets, enum-driven validation rules, API serialisation conventions, or audit logging of state transitions. None of that is in scope here.
• You need a supported dependency with SLAs, active issue triage, or broad community validation. Low adoption is the main risk signal, not code quality.
• The enum surface is small (one or two fields) — a bespoke field is less total cost than onboarding, pinning, and owning a fork.
• Your enums change shape often and you want the admin UI generated from a schema rather than per-field configuration.

How to Pitch It (Stakeholders)

To executives: A small, MIT-licensed open-source add-on for our existing Laravel Nova admin panel that makes enum-backed statuses (order states, account states, roles) readable and filterable for operations staff. Zero licence cost, no infrastructure change, and a contained integration — days, not a project. The latest release keeps it current with Laravel 12 and Nova 5, so it will not block our platform upgrade path; it does require PHP 8.2 and Laravel 11+, and it drops Laravel 10. The catch is unchanged: it is a low-adoption package from a single maintainer, so we would vendor it and treat it as our own code rather than depend on upstream support. Net: a low-cost UX improvement to internal tooling, contingent on our continuing to run Nova and being past the Laravel 10 / PHP 8.1 line.

To engineering: It is a thin Nova field and filter that map PHP 8.2 backed enum cases to labelled options, plus filters that let admins query by case. It aligns the admin layer with the enum modelling we already want in the domain. v3.3.0 is a maintenance release: Laravel 12.x and Nova 5.x added, Laravel 10.x and PHP 8.1 dropped — no API or behavioural changes, but it is a hard platform floor, so check each target app's PHP/Laravel versions before pinning. Integration is small; the honest framing is that we could replicate it in about a day, so the decision is really "adopt and vendor" versus "write and own" — both are fine, and the package is worth it mainly if the same need shows up across more than one project. Recommend pinning the version, reviewing the source once (it is small), and forking under our namespace if we adopt.