Nova Radio Field Laravel Package

Technical Evaluation

Architecture fit. This is a presentation-tier Nova form field: one PHP field class plus a compiled Vue component, ~100–200 lines of code total. It touches no domain logic, persistence, queues, or data egress. Stored values are ordinary scalar columns, so the package sits entirely in the admin UI layer and imposes no architectural constraints on the application. That is the strongest thing about it — it is trivially isolatable. The corresponding weakness is that there is no architecture-level reason to adopt it: the same fit is achievable with a native Nova field or a plain Select at zero dependency cost.

Integration feasibility. Install is mechanically simple (composer require, Nova service-provider autodiscovery, nova:publish, hard refresh), but install success is not integration success. The real risk surface is the prebuilt dist/ bundle: a Vue component compiled against a different Nova minor can load without error and fail silently at runtime. Namespace verification against src/ is required before writing use statements — the package name, repo org, and author namespace do not agree. The genuine integration work is a staging verification matrix, not the require.

Technical risk. Concentrated and asymmetric:

• Archived upstream (Dec 2023), single maintainer, zero dependents. No CVE pipeline, no compatibility fixes, no one else has absorbed the discovery cost. Every future Nova bump becomes an unbudgeted migration line item.
• Likely redundancy. Recent Nova majors ship a native Radio. If that covers the requirement, this package is dead on arrival and the assessment ends there. This must be answered first, not last.
• Asset/toolchain drift. Nova 4+ moved between Mix-era and Vite-era builds; the shipped bundle matches whatever the author had, not whatever you have.
• Client-side-only constraint. The field's rules() is a UX affordance. Server-side validation remains the trust boundary and must be built independently.
• Discovery cost lands internally. Zero dependents means no community bug reports — your team finds the edge cases (null handling, conditional visibility, index vs. detail label rendering) in production.

Key questions.

1. Which Nova major and exact minor are in composer.lock, and does the native field set already provide Radio? (If yes: stop.)
2. Is the radio-over-select interaction a validated operator requirement, or an assumed preference? What is operators × edits/week × mis-selection rate?
3. What is the OSS policy on archived dependencies in operator-facing surfaces, and does the MIT vendoring path satisfy it?
4. Who owns the code if it breaks during a Nova upgrade, and what is the retirement trigger?
5. Can the team spare ~1 engineer-day to build/vendor it rather than depend on a remote that can vanish?

Recommendation. Do not add it as a Composer dependency. Either use the native Nova field, or — if the UX is genuinely required and unavailable natively — vendor the MIT source into app/Nova/Fields with attribution and treat it as first-party code. Adoption cost exceeds build cost with a permanent maintenance tail and no compensating upside.

Integration Approach

Stack fit. Laravel + Nova only; no database, cache, or queue involvement. The field maps to an existing string column, so there is no schema change, no cast, no migration. This is the cleanest possible integration profile and the reason the decision can be made cheaply.

Sequencing. Strictly gated, one resource first:

1. Floor check. Confirm Nova version and native field coverage. If native Radio exists and works, close the ticket.
2. Requirement check. Confirm the interaction with actual operators and put a number on the benefit before spending sprint capacity.
3. Policy check. Apply whatever archived-dependency rule the team wants to set — this is a low-stakes first application of it.
4. Vendor or skip. Copy the source into app/Nova/Fields/ with the MIT notice and a header attribution comment; lint and test it as normal Nova field code.
5. Single-resource pilot. One bounded enum (2–5 options) with single source of truth: an enum's options() feeding the field, Rule::enum() in the FormRequest.
6. Full matrix verification in staging — create, update, detail, index, null/default save-and-reload, and conditional visibility.
7. Widen only after one clean deploy cycle, with an ADR recording decision, owner, and exit criteria.

Compatibility. Pinned to older Nova majors (3.x/4.x) and only against the exact minor verified in production. An archived package is a guaranteed blocker on a Nova 5 upgrade and must be scoped as such before any upgrade planning. If dependency adoption is forced by policy, pin an exact version and mirror the source alongside the lockfile so builds never reach a remote that can disappear.

Migration path (in and out). In: a few lines per resource, no data change. Out: swap the field class back to Select or native Radio in the resource definition — a one-line change with no data migration, because values are plain columns. This reversibility is the single strongest argument for trying it at all, and it should be stated explicitly so the team does not over-deliberate a low-stakes choice.

Anti-patterns to block up front. Do not retrofit every select across the admin. Do not use it for option sets beyond ~5–7 entries. Do not rely on the field for data integrity. Do not assume consistent label rendering across index/detail/form — test each context.

Operational Impact

Maintenance. The clock starts at install. With upstream archived, this becomes a permanent fork whether or not you call it one: no upstream issues, no compatibility patches, no security response. Budget it as first-party code with a named owner in the internal component inventory and a written retirement trigger (e.g., "delete when we move to native Nova radio"). If owned without documentation, it degrades into an orphan nobody dares touch before the next Nova upgrade forces the question.

Support. No vendor, no CVE pipeline, no maintainer responsiveness. Anything a procurement or compliance review asks — patch cadence, security disclosure path, maintainer continuity — has no answer. That likely disqualifies it from operator-facing paths under most governance regimes, and it is the cleanest reason to prefer vendoring, which at least gives you a party to hold accountable: yourself.

Scaling. The field does not scale, and neither does the dependency model.

• Interaction scaling: past ~5–7 options radios dominate the form and scan worse than a select; large or dynamic sets want a searchable select.
• Surface scaling: each additional resource is a few lines of code but another place to verify the display behavior matrix and another consumer of an unmaintained asset bundle.
• Upgrade scaling: cost recurs on every Nova bump rather than amortizing.

Failure modes (ranked by likelihood, not severity):

1. Asset bundle mismatch — install succeeds, UI silently breaks under a different Nova minor. Detect via browser console and network tab for a 404 on dist/js/field.js before debugging PHP.
2. Class-not-found from a wrong namespace derived from the package name rather than src/.
3. Label/value drift between the options array, the validation rule, and model handling — the classic recurring bug; solved only by enum-backed single source of truth.
4. Nullable/empty semantics — whether nothing-selected persists null or ''; undocumented upstream and never to be documented, so it must be asserted in tests.
5. Conditional-visibility breakage — the field appearing/disappearing under dependsOn is the standard failure surface for custom Nova fields and will never be patched upstream.
6. Server-side validation gaps — a crafted request ignores client rules entirely.

None of these are severe; all of them are yours to find. That is the operational tax on a package that saves roughly one engineer-day.

Ramp-up. Low for any Laravel/Nova developer — the field API is conventional (options(), default(), rules()), and the source is auditable in an afternoon. The ramp-up cost is not learning the package; it is learning its undocumented edges (null behavior, index vs. detail rendering, conditional visibility), which is discovery work rather than documentation. Mitigate by writing the verification checklist into the PR — it will be the only documentation this component ever has — and by keeping the pilot to one resource so the exit remains a one-line change.