Nova Enum Field Laravel Package

Product Decisions This Supports

• Build vs. buy for internal admin tooling. Nova is already the "buy" decision; this package is a thin, MIT-licensed extension of it. If we standardize on enum-backed state columns, it replaces N hand-rolled Nova field + filter classes with one dependency — a direct reduction in the custom code our team owns and maintains.
• Unblocking (or de-risking) the PHP 8.1 enum refactor. Teams stall on native enums because admin surfaces regress: labels disappear, index filters break, saved support views stop working. A drop-in enum field removes that objection and unblocks a domain-modeling roadmap item that would otherwise slip a quarter.
• Roadmap sizing for back-office work. Each enum-backed state column (order status, subscription lifecycle, ticket priority, KYC state) typically costs 0.5–2 engineering days of bespoke Nova field and filter work. With three or more planned, adoption pays back inside a quarter — a sizing input, not a strategy shift.
• Operational self-service, including relation-scoped views. Filterable enum columns let support and ops slice queues by state without filing engineering tickets. v1.11.1 specifically fixes filtering on index views rendered through a relation (e.g., the "Orders" panel on a customer detail page) — where support actually spends time — so the self-service benefit now extends to nested queues, not just top-level lists.
• Dependency risk classification. 19 stars, zero dependents, single maintainer: classify as a vendored utility, not a strategic dependency. v1.11.1 is a modest positive signal — an actively triaged bug with a named contributor fix — but a patch release does not upgrade the risk class. Keep the vendor/fork framing in the decision record.
• Explicit non-goal. This does nothing for customer-facing UX and does not by itself justify Nova spend or an admin-platform program. Scope it as internal-tooling spend only.

When to Consider This Package

Consider it when:

• You are on Laravel Nova (confirm the major version — v4 vs. v5 support is the gating question) with PHP 8.1+, and native enums are already used or planned for domain state.
• You want label mapping plus index filters for those enums without hand-writing a field class and filter class per enum.
• You need filters to work on relation-rendered index views (hasMany/belongsTo panels), not just top-level resource indexes — the case v1.11.1 addresses, and the configuration most likely to surface API-fit issues.
• Your enums are backed (string or int) and cast on the model, so there is a scalar value for filters to compare against.
• You are willing to own maintenance — the code surface is a few hundred lines, so forking and pinning in-repo is cheap and low-drama.
• You have at least three enum-backed columns; below that, a plain Nova Select with an options array is roughly twenty lines and not worth a dependency.

Look elsewhere when:

• Admin is Filament, Inertia, Blade, or custom — the package is Nova-specific and adds nothing.
• PHP < 8.1, or enums are stored as raw strings without casts, so there is nothing to map.
• Your dependency policy forbids single-maintainer packages or requires vendor SLA/support.
• You plan to migrate off Nova within 12 months, or the enums are highly presentational and need bespoke UI beyond label/color.
• Verification fails. Release cadence is now partly evidenced by a v1.11.x patch line, but Nova major-version compatibility is still unconfirmed and must be checked against the repo, not assumed. If relation-based filters are absent from your admin, the main reason to care about this specific patch disappears — and so does most of the near-term value.

How to Pitch It (Stakeholders)

For executives. This is a small, free (MIT) add-on for our internal admin panel. It makes status-type data — order states, subscription stages, ticket priorities — filterable for support and ops without custom engineering work, including on the related-record panels support uses most. The cost is roughly one engineering day to evaluate and vendor; the risk is low and fully reversible, because a fork is a few files. The latest patch is a routine bug fix, not a feature expansion or a breaking change — evidence the package is still looked after, not a reason to expand scope. It is not a platform commitment and should not be read as justification for the Nova license itself. Recommendation: approve a timeboxed spike, not a program.

For engineering. The package supplies a Nova field that renders PHP 8.1 enum cases with label mapping, plus matching filter classes so enum columns are filterable on Nova index views. v1.11.1 is a patch release with no API changes: it fixes an exception (#8) thrown when EnumFilter or EnumBooleanFilter is applied to a resource index rendered through a relation. Practical implications: (1) upgrading is low-risk and worth taking if we already depend on it — the fix removes a crash path rather than adding surface area; (2) add a regression smoke test that exercises an enum filter on a relation-rendered index, since that path was previously broken and is the one most likely to regress across Nova upgrades. Practical notes: use backed enums only; implement HasLabel for display labels; don't mix ->options() with ->enum(); pick EnumBooleanFilter for binary enums and EnumFilter for multi-case enums; keep the model cast as the source of truth and validate with Rule::enum. Ask: verify Nova major-version compatibility and filter API fit, vendor or fork the code in-repo, pin the version, and keep the smoke test running on every Nova upgrade.

Decision and gate. Timebox the evaluation to 0.5–1 day; adopt only if Nova compatibility is confirmed in-repo and at least three enum-backed columns are on the roadmap within two quarters. Otherwise default to plain Select fields and revisit when the enum footprint grows.