Nova Radio Field Laravel Package

Product Decisions This Supports

• Whether admin form polish earns sprint capacity at all. A radio field is a presentation-tier widget: it removes one click per edit for bounded enums (statuses, priorities, 2–5 option flags). That is a real but small benefit — put a number on it (operators × edits/week × mis-selection rate) before it competes with anything on the roadmap. Until then it is a preference, not a requirement.
• Build vs. buy for a ~100–200 line UI primitive. This package is the "buy" option, and the buy price is not the license — it is permanent ownership. Upstream is archived, so "adopting" actually means forking. The equivalent build is roughly one engineer-day including tests. Adoption cost exceeds build cost with no offsetting upside, and that comparison is the decision.
• Setting a dependency-governance precedent. This is a cheap, low-stakes test case for whatever policy the team wants to hold: "no archived dependencies in operator-facing paths," "no zero-dependent packages in admin surfaces," "no prebuilt assets we cannot rebuild." Whatever line you draw here propagates to the next dozen component choices, and it is far easier to hold firm on a 5-star abandoned field than on a popular package with internal pressure behind it.
• Clarifying Nova upgrade exposure. If the roadmap contains a Nova 5 upgrade, an archived field package is an unbudgeted line item on that migration and a probable blocker. Deciding "no" here keeps the upgrade path clean.
• A deliberately bounded, reversible bet. Stored values are ordinary string columns — no migration, no cast, no schema. Swapping back to Select or a native field is a one-line change per resource. Say this out loud so the team does not over-deliberate on a decision whose cost-of-being-wrong is near zero.
• Explicitly not a platform, architecture, or vendor-strategy question. There is no domain logic, persistence layer, or data egress involved. If a proposal elevates this to a strategic decision, that is a signal to push back, not to escalate.

Recommendation: do not adopt the Composer dependency. Either use the native Nova radio field (verify it exists in your Nova major first — it likely does), use a plain Select, or vendor the MIT-licensed source into app/Nova/Fields with attribution and a named owner. Ship it behind a single resource, then decide whether it widens.

When to Consider This Package

Consider it only if all of the following hold:

• You are pinned to an older Nova major (3.x/4.x) and have verified the field against the exact minor running in production. Last release was December 2023 and the repo is archived — no compatibility fixes are coming.
• The radio interaction is a validated operator requirement (confirmed with users, not assumed), and neither the native Nova radio field nor a plain Select covers it. Answer this first; recent Nova majors ship a native Radio, which likely makes the package redundant.
• Nobody can spare the ~one engineer-day to write the field, and the business accepts owning a fork indefinitely with a named owner and a retirement trigger.
• Legal/OSS policy accepts the vendoring-and-attribution path — which is strictly better than depending on an archived remote, and is the only route worth taking if you proceed at all.

Look elsewhere — or build — when:

• You are on Nova 5 or plan to upgrade. An archived package is a guaranteed migration blocker and an unbudgeted line item on every future bump.
• You need maintained dependencies, security response, or anything a procurement/compliance review will ask about. There is no vendor, no CVE pipeline, no maintainer responsiveness, and zero dependents means nobody else has absorbed the discovery cost for you.
• Option sets are large or dynamic. Radios do not scale past roughly 5–7 choices; you want a searchable select.
• You need conditional visibility, custom styling, accessibility guarantees, localization, or richer validation. Upstream will never ship those, so they become your scope — at which point you are building anyway.
• The signal set is read honestly: 5 stars, 0 dependents, no release in over a year, archived. That is not a hidden gem.

How to Pitch It (Stakeholders)

For executives: This is a small radio-button widget for our Laravel admin panel — not a platform bet — and my recommendation is not to adopt it. It has been archived by its author, has a single maintainer, zero downstream users, and no release since late 2023. Taking it on means owning it forever, including every future Nova upgrade. The equivalent is about one engineer-day to build, and because it is MIT-licensed we can copy the source outright if we want a head start. Adoption cost exceeds build cost, with a permanent maintenance tail and no upside. The good news is the decision is small and reversible: values live in ordinary database columns, so switching later is a code change with no data migration. I am using this as the first application of a simple policy — no archived dependencies in surfaces our operators depend on.

For engineering: MIT-licensed Nova radio field, archived, zero dependents, no Nova 5 path. Likely redundant with the native radio field in recent Nova majors — confirm that in composer.lock before anything else; if native works, the assessment ends. If we do want custom radios, two options, both cheaper than dependency adoption: (1) vendor the field class and Vue component into app/Nova/Fields with the MIT notice retained, own it as first-party code with a named owner and a retirement criterion, or (2) use native Radio/Select and spend the day elsewhere. Do not add the Composer dependency unless policy forces it; if it does, pin an exact version and mirror the source alongside the lockfile. Verification is the expensive part, not install: prebuilt dist/ assets can load fine and still fail at runtime against a different Nova minor, so budget a staging spike covering create, update, detail, index, conditional visibility, and null/default save-and-reload. Roll out behind one resource first, and record the ADR — decision, rationale, owning team, exit criteria. One integrity note: the field constrains only browser input; enforce the enumeration in backend/resource validation with Rule::enum or in:, sourced from the same definition as the field options so they cannot drift.