Nova Radio Field Laravel Package

Technical Evaluation

Architecture fit

• Leaf-node presentation dependency: one Laravel\Nova\Fields\Field subclass plus one compiled Vue component. No service provider, config publish, migrations, routes, middleware, or auth surface. Nova auto-discovers it.
• Correct fit only if Laravel Nova is already the system of record for back-office admin. Outside Nova the package has zero applicability and the evaluation ends.
• Scope is intentionally narrow: a small, mutually exclusive option set (≈ ≤5 values) rendered as inline radios, driving show/hide of a handful of sibling fields in the same form. It is not a rules engine, not cross-resource conditional logic, and not a wizard.
• It overlaps Nova's native Field::dependsOn() (3.14+). What the package actually sells is the radio affordance plus a terser toggle API — not conditional visibility itself. That framing matters for build-vs-buy.

Integration feasibility

• Integration is a composer require plus swapping a Select for a Radio on a resource you own. Hours, not days, assuming compatibility passes.
• The blocker is not integration effort, it's the compatibility gate. Last release July 2021 predates Nova 4's Vite-based asset pipeline and Vue 3, and release 1.0.1 only removed an unused CSS dependency — a signal of low recent investment.
• The PHP class is very likely fine on newer Nova; the shipped dist/js bundle is the fragile artifact. It can render blank or throw inside the form's shared Vue tree without producing a build error.
• Reversibility is good: swap back to Select and stored option keys remain valid, provided the option set is unchanged.

Technical risk

• Compatibility (high, unquantified): no documented Nova 4/5 support. Failure is silent and discovered at render time.
• Supply chain (high, certain): single maintainer, 34 stars, zero dependents, ~4 years without a release, no vendor support. Any adoption converts upstream maintenance into an internal obligation.
• Data-shape (medium): Nova stringifies field values, so integer option keys (1, 0) won't reliably match in ->toggle(). Requires string keys or a resolve cast.
• Composition (medium): toggled targets must exist in the form tree; conditionally omitted children break the JS listener. Two radios targeting the same field overwrite each other's visibility — last render wins.
• Accessibility (unverified): source is the only answer as to whether this is a real keyboard-navigable radio group or styled markup. That is a baseline requirement, not a nice-to-have.
• Blast radius (contained): worst case degrades one authenticated admin form panel. No data corruption path, since persistence is standard Nova field behavior.

Key questions

1. What exact Nova version(s) are in production, and does the bundle render there — verified, not assumed?
2. Does the radio affordance actually serve a UX requirement, or would Select + dependsOn() clear the bar at lower total cost?
3. How many resources will need this pattern? One is a convenience; five is a roadmap item for a shared field factory.
4. Who is the named owner of the fork, and is there a line item in the next Nova major-upgrade plan?
5. Are fork-and-vendor rights confirmed under the license, and does it clear our supply-chain policy?
6. Does the rendered control meet our keyboard/screen-reader baseline?
7. Can we live without vendor support for a field that appears in operational workflows staff use daily?

Integration Approach

Stack fit

• Laravel + Nova only; Composer-distributed; no runtime services, queues, or storage. Pin the version explicitly in composer.json.
• Preferred target state is vendored into nova-components/ as an owned component rather than consumed as an upstream dependency — the code is small enough (one PHP class, one Vue file) that owning the build is cheaper than owning the risk.
• Where a radio affordance is not a genuine requirement, the lower-total-cost path is a standard Select with native dependsOn(). Treat that as the default and require justification to deviate.

Migration path

• Additive and non-breaking: no schema change, no data migration. Option keys persist exactly as a Select would.
• Existing records whose stored value falls outside the configured option set will render as a raw key — audit values before swapping the field on any resource with historical data.
• Rollback is a one-line field swap back to Select; no cleanup required.

Compatibility

• Gate on a half-day, throwaway-branch spike against the exact Nova version in production. Check the package's composer.json constraints and the shipped dist/js bundle directly — the README will not tell you whether it works on Nova 4/5.
• Pass criteria, all required: Composer resolves cleanly against laravel/nova; field renders inline; value persists on create and update; validation errors display correctly; ->toggle() hides and shows the target field; keyboard navigation works; no console errors; coexistence with a native dependsOn() field on the same resource.
• Deliberately point a toggle at a non-existent attribute as a smoke test — that confirms the listener is wired at all, and separates "JS not loaded" from "attribute name wrong."

Sequencing

1. Spike (0.5 day): throwaway branch, single low-traffic resource, all pass criteria above. Hard stop if any fail.
2. Decide: pass → vendor and own. Fail → internal build of the same field (contained, a few hours) or fall back to Select + dependsOn().
3. Vendor and pin: move into nova-components/, remove the upstream requirement from composer.json, assign a named owner, record the build step.
4. Pilot: one low-traffic authenticated resource. Hold for one release cycle before spreading.
5. Centralize before the second resource: extract a shared field factory (a static make() returning a pre-configured Radio) so toggle rules live in one place rather than drifting across resources.
6. Upgrade hook: add the fork to the checklist for every Nova major upgrade, alongside the compatibility re-test.

Operational Impact

Maintenance

• Maintenance transfers to us on adoption. The code is trivially readable and cheap to patch, which is the mitigating factor — but the obligation is real and recurring, concentrated on Nova major upgrades when the Vue bundle must be re-validated.
• Mitigations: pin the version, vendor the component, name an owner, and enforce the pin in CI so an unattended composer update cannot silently change the field's behavior.

Support

• No upstream support, no SLA, no security-response channel. Assume issues are diagnosed and fixed internally, and budget accordingly.
• Do not adopt if our policies require vendor support or maintained-dependency guarantees for production tooling. This fails that bar on the facts.
• Internal support cost is low in practice: the API surface is ->options(), ->toggle(), and inherited Nova field modifiers. There is nothing to learn beyond that.

Scaling

• Runtime scaling is a non-issue: client-side rendering only, no server load, no query cost, no storage.
• Codebase scaling is the risk. Copy-pasted toggle maps across resources drift and become unmaintainable; the shared field factory is the required pattern past the first resource. Conflicting toggles on a shared target field are the predictable symptom.
• Functional scaling is capped by design: small mutually exclusive option sets, form view only. ->toggle() is ignored on index and detail — that is expected behavior, not a defect. Multi-step branching or cross-resource conditions must go elsewhere.

Failure modes

• Blank field in the form panel: compatibility mismatch, most likely on Nova 4/5.
• Silent no-op toggle: renamed attribute, missing target in the form tree, or bundle not loaded. Diagnose in the browser console first — these fail quietly.
• Vue tree exception: a render error can affect sibling fields in the same form, which is broader than the field itself but still confined to one admin screen.
• Integer option keys: toggle matching fails intermittently because Nova stringifies values. Enforce string keys at code review.
• Degradation is contained — no data loss, no auth surface, no customer-facing exposure. This is precisely why the package is acceptable for internal admin screens and not for anything else.

Ramp-up

• Near zero for a Laravel/Nova developer; the fluent API mirrors standard Nova field methods. A 60-second read of the single PHP class and Radio.vue covers the entire surface.
• The real ramp-up is organizational, not technical: establishing the vendor-and-own workflow, the spike gate, the named owner, and the upgrade checklist. That is roughly a day of setup and then negligible.
• Documentation is thin and does not state Nova 4/5 support — plan on source review and empirical testing rather than reading docs.

Recommendation Adopt conditionally: run the half-day compatibility spike, pilot on one low-traffic resource, and proceed only with a named owner, a vendored build, and a fork obligation recorded against the next Nova upgrade. Time saved is a few engineering hours on a custom field; the cost accepted is permanent, low-grade ownership risk on a single-maintainer package. Where the radio affordance is not a genuine UX requirement, Select + dependsOn() is the lower total-cost answer and should be the default.