Nova Radio Field Laravel Package

Product Decisions This Supports

• Prioritizing admin-tooling UX against the roadmap. The package exists to make a small, high-traffic class of internal forms — status, role, plan, approval state, feature flag — legible at a glance and to hide the fields that don't apply. That is a defensible use of a sprint-day when the same screens are used daily by operations staff, and it's a clear "no" when the surface is customer-facing or low-traffic. The decision this supports is prioritization, not platform architecture.
• Build vs. buy, stated honestly. Buying here means adopting one PHP Field subclass and one compiled Vue component, not a platform. The realistic framing is "a few engineering hours saved against a permanent fork obligation." Because the last release predates Nova 4's asset pipeline, the buy side of the ledger carries a compatibility spike and an ownership transfer; the build side is a contained internal component with the same behavior. Present both costs to the same stakeholder in the same meeting.
• Roadmap scoping: one-off vs. recurring capability. If exactly one resource needs conditional reveal, this is a tactical convenience. If three or more do, the roadmap item is not "adopt a package" — it's "standardize conditional admin form behavior," delivered as a shared field factory or as native Select/Boolean plus dependsOn(). This package is a useful probe for whether the need is real before you commit headcount to a shared abstraction.
• Acceptance criteria for any conditional-visibility feature. Independent of whether you build or adopt, the bar should be: renders inline, persists identically on create and update, surfaces validation errors on the field itself, toggles the correct sibling fields by attribute name, does not conflict with Nova's native dependsOn(), and is keyboard-navigable. Writing these down now means the make-or-buy call gets made on evidence rather than demo.
• Risk budgeting for the Nova upgrade path. Every Nova major is a potential break for any community field, and disproportionately for ones with a prebuilt bundle. This package forces that cost into the open: pin the version, name an owner, and add a line item to the next upgrade plan. The blast radius is one authenticated form panel — degraded, not down — which is exactly the profile of risk worth accepting with a plan and not worth accepting silently.
• Explicit non-goals. Not for customer-facing forms, not for multi-step branching workflows, not for anything requiring vendor support or a security review of the dependency chain. Documenting that boundary is itself a product decision, and it prevents scope creep from turning a convenience into a load-bearing dependency.

When to Consider This Package

• Laravel Nova is already central to operations. No Nova, no evaluation. There is no applicability outside Nova resource forms.
• The need is narrow, declarative, and small. A single mutually exclusive choice (roughly five options or fewer) driving visibility of a handful of sibling fields defined in the same fields() array. Not a rules engine, not cross-resource logic, not a wizard.
• You can pass a compatibility gate before committing. The 2021 release predates Nova 4 and 5. Budget a half-day spike on your production Nova version: confirm Composer resolution against laravel/nova, confirm the shipped dist/js bundle renders inside the form's Vue tree, and exercise create, update, validation-error, and toggle states on one low-traffic resource. Check composer.json and the bundle — the README will not tell you.
• You are prepared to own it. Single maintainer, ~34 stars, zero dependents, no release since July 2021. Adopt only with a fork-and-vendor plan (into nova-components/), a pinned version, a named owner, and a license check that permits forking.
• The radio affordance is a genuine UX requirement. If a Select with native dependsOn() already satisfies the requirement, the only thing you're buying is the radio buttons — and that is rarely worth a dependency.

Look elsewhere if: you're on an untested Nova release and won't fund the spike; your accessibility baseline requires verified keyboard and screen-reader semantics and the control turns out to be styled markup; supply-chain policy disallows unmaintained single-maintainer packages; the visibility rules are complex or will be duplicated across many resources (centralize in a shared factory instead); or two radios would target the same field, toggled fields are conditionally omitted from the form, or option keys are integers — Nova stringifies values and the toggle matching becomes unreliable.

How to Pitch It (Stakeholders)

Executive summary. A small accelerator for internal admin screens: it presents a short set of mutually exclusive choices as inline radio buttons and reveals only the follow-on fields that matter for the selected choice. Cleaner forms, fewer mis-entries on status and settings screens, marginally faster delivery of back-office tooling. It is a tactical convenience, not a platform bet, and it carries a known cost — the package is four years stale and would become ours to maintain. Recommend approving a half-day compatibility spike, with the expectation that the outcome is "fork and own," not "adopt and rely on."

For engineering. Treat this as a time-saving Nova field, not a long-term dependency. The surface is tiny and readable in an hour: one Field subclass plus one Vue component, with ->options(), ->toggle(), and the inherited Nova modifiers. The risk sits entirely in the bundle — built against Nova 3-era tooling, it can go blank or throw inside the shared form Vue tree with no build error. Gate on a throwaway branch: Composer resolution, render, persistence on create and update, validation-error display, toggle behavior, and coexistence with native dependsOn(). Pass → vendor into nova-components/, pin the build, assign an owner, and add revalidation to the Nova upgrade checklist. Fail → the same behavior is a contained internal build of roughly equal size.

For product and operations. Staff see only the fields relevant to the choice they made, which cuts clutter and mis-entry on the screens they use every day. The trade is supply-chain risk on an old, single-maintainer package with no dependents. Manage it by piloting on one low-traffic resource, keeping the toggle rules centralized in a shared factory so they don't drift across resources, and accepting that we — not upstream — fix anything that breaks. Do not extend it to customer-facing forms or complex conditional workflows, and mark the next Nova upgrade as the moment the fork gets re-validated.