Nova Enum Field Laravel Package

Technical Evaluation

Architecture fit

• simplesquid/nova-enum-field remains a thin presentation-layer extension for Laravel Nova: a custom Field class plus index/filter implementations that render PHP BackedEnum values. It does not touch persistence, domain logic, or the enum itself, so it slots into an existing Nova resource layer without altering application architecture.
• Architectural dependency is the critical constraint: value is realized only if the platform already runs Nova (paid, proprietary) and the domain model uses native enums. Without both, the package has no surface to attach to. v3.3.0 does not change this — it only moves the supported Nova floor forward.
• The coupling is shallow and reversible — a Nova field is a PHP class + Vue component — so worst-case replacement is a custom field roughly equivalent in size.

Integration feasibility

• Straightforward within the supported matrix: composer require simplesquid/nova-enum-field, then swap a Select/Text field for the package field on a resource and register the matching filters. No migrations, no service providers to wire beyond package discovery.
• v3.3.0 narrows that matrix. It adds Laravel 12.x and Nova 5.x, and drops PHP 8.1 and Laravel 10.x. Any environment still on PHP 8.1 or Laravel 10 is now pinned to the prior release line and receives no further updates. Confirm our runtime matrix before this release is treated as adoptable.
• Prerequisite work still sits in the domain, not the package: string/int columns and class constants must already be modeled as BackedEnum. If they are not, the integration is blocked on an enum refactor, which is the real cost — not the field swap.
• Low blast radius supports a single-resource pilot with quick rollback.

Technical risk

• Version-skew risk (now highest). v3.3.0 is a forward-only compatibility release: it adds Laravel 12 / Nova 5 while removing PHP 8.1 / Laravel 10. The notes do not state whether Nova 4.x remains supported. If Nova 5 is required, teams on Nova 4 are stranded on the previous release with no upgrade path short of a Nova upgrade. Treat the supported Nova range as an open question, not an assumption.
• Abandonment / single-maintainer risk (still high). 52 stars, 0 dependents, small maintainer shop: no community safety net and no SLA. The v3.3.0 release is a positive maintenance signal — the project is tracking current Laravel and Nova majors — but it does not create redundancy.
• Deprecation runway. Dropping PHP 8.1 and Laravel 10 in a minor-version bump (3.3.0) signals that support windows here track upstream majors closely and may not be announced well ahead of time. Budget for forced upgrade cadence rather than opt-in upgrades.
• Nova version coupling. Nova's field and filter APIs have shifted across majors; this release is direct evidence of that. An unpinned Nova upgrade can silently break rendering or filter behavior. Version constraint hygiene is mandatory.
• Low signal on quality. Score 1.23 and zero dependents indicate negligible production validation; assume you are an early adopter and budget for reading the source. v3.3.0 is untested by the broader ecosystem.
• Mitigant: the package is MIT and small. Fork-and-vendor is a realistic contingency, which caps risk at "hours of engineering" rather than "blocked roadmap."

Key questions

1. Are we on Nova 4 or Nova 5, and is it pinned? If Nova 4, does v3.3.0 still support us, or are we frozen on the prior release?
2. Are we on PHP 8.1 or Laravel 10 anywhere in the estate? If so, does that platform need to stay on the old package line, and who owns that fork?
3. Do our domain models already use native backed enums, or is this package implicitly funding an enum refactor?
4. Do we need enum-aware filters (the differentiating feature) or only display/edit? If only display, a stock Select with an options map may suffice.
5. Are enum labels localized, and does the package honor HasLabel/translation hooks?
6. Do we need multi-select or nullable enum handling, and does the package cover it?
7. What is our exit plan — fork, vendor, or revert to stock fields — and who owns it?

Integration Approach

Stack fit

• v3.3.0 fits Laravel 11–12 + Nova 5.x + PHP 8.2+. Clean where enum-backed status/type/category columns already exist and are surfaced in Nova admin resources.
• Poor fit where Nova is absent, PHP 8.1 or Laravel 10 is still in play, enum-like data is simulated with constants and lookup tables, or Nova is pinned below 5.x.

Migration path

1. Run a compatibility audit first: inventory PHP, Laravel, and Nova versions per application. This gate now precedes everything else — v3.3.0 is a breaking change for PHP 8.1 / Laravel 10 environments.
2. Inventory Nova resources with enum-like Select/Text fields and their underlying columns.
3. Confirm columns are backed by native enums; if not, sequence the enum refactor first (separate, larger workstream).
4. Install with an explicit version constraint matching our Nova major version. Do not use a floating constraint — a future minor could drop our Laravel or Nova major.
5. Replace fields resource-by-resource behind a feature flag or Nova permission gate; keep the prior field definition in a branch for instant rollback.
6. Add filters only after field parity is confirmed.
7. Re-run the full sequence on Nova major upgrades; treat each as a re-integration, not a patch.

Compatibility

• Pin both the package and Nova, and pin the package to an exact minor. v3.3.0 demonstrates that minor releases here can carry breaking platform drops.
• Verify against our exact PHP/Laravel/Nova matrix in CI, since dependents are zero and we cannot rely on others discovering breakage. Add the matrix to the CI matrix definition so drift fails the build loudly.
• Confirm Nova 4.x support status directly with the maintainer or by reading the composer.json constraint before planning any Nova upgrade.

Sequencing

• Week 1: compatibility audit (PHP/Laravel/Nova versions across apps) + version matrix validation + one resource pilot on Laravel 11/12 + Nova 5 (display/edit only).
• Week 2: filter rollout on 2–3 high-traffic resources; document label/localization behavior.
• Week 3: go/no-go based on pilot friction; decide fork-vs-depend and record the decision. Any app still on PHP 8.1 / Laravel 10 gets an explicit "frozen on prior release" decision, not a silent one.

Operational Impact

Maintenance

• Low steady-state effort — pure UI-layer code with no runtime services. The recurring cost is upgrade surveillance, and v3.3.0 raises it: every Laravel, PHP, and Nova bump requires a compatibility smoke test, and upstream may drop our major without a long runway.
• Own the constraint pins and a documented fork procedure; do not depend on upstream responsiveness or on deprecation notices arriving early.

Support

• Community-only, effectively single-maintainer support. No vendor SLA. Internal ownership must be assigned explicitly, with source-reading capability assumed.
• Acceptable only because the code surface is small enough to fork in-house if upstream stalls, or if upstream drops the PHP/Laravel/Nova version we are stuck on.

Scaling

• Negligible performance impact: rendering-time only, no queries, no background work. Scales with Nova page views, not data volume.
• Complexity scales with enum count and filter permutations, and with the number of applications in our estate drifting onto different PHP/Laravel/Nova versions.

Failure modes

• Version-skew failure (new, likely). A package minor drops our PHP or Laravel major → install or upgrade resolves to a version we cannot run, or a floating constraint silently adopts a breaking drop. Mitigate with exact pins and a CI matrix gate.
• Nova 4 stranded. If Nova 5 is required and we are on Nova 4, the upgrade path is blocked upstream in Nova, not in this package. Decide explicitly: upgrade Nova, or fork the previous release line.
• Nova upgrade breaks the field component or filter contract → admin screens degrade or error. Detect via CI smoke tests on Nova upgrades.
• Upstream abandonment → no fixes for new Nova/PHP versions. Mitigated by MIT fork.
• Enum/label drift → filters silently match nothing if enum cases change without updating filter definitions. Add enum cases to code review checklists.
• Team unfamiliarity with native enums → misconfigured field definitions. Mitigate with a short internal pattern doc.

Ramp-up

• A Nova-experienced Laravel developer needs ~2–4 hours to pilot a resource and ~1 day to roll out fields plus filters across a typical admin surface — provided the environment already satisfies the v3.3.0 matrix.
• Add 2–5 days if a PHP 8.1 → 8.2+ or Laravel 10 → 11+ upgrade must land first; that upgrade, not the package, is the schedule driver for this release.
• Teams without native-enum experience should add 1–2 days for enum modeling conventions before adopting the field; otherwise the package is adopted ahead of the prerequisite it depends on.