Filament Radio Button Field Laravel Package

Technical Evaluation

Architecture fit. This is a leaf-level presentation component: a Filament form field plus (presumably) a Blade view and some styling. It carries no persistence layer, no domain logic, no background work, and no meaningful service-provider surface. That makes it architecturally cheap to adopt — there is nothing to couple to your domain model, and nothing that can corrupt data on its own. Fit is high conditional on a real need: Filament already ships a Radio field, so this package only earns a slot if it closes a specific, articulable UX gap (compact/inline option groups, native browser radio rendering, custom option templates, density in large option sets). If the requirement is simply "a radio field," the correct answer is the built-in component.

Integration feasibility. Mechanically trivial — a composer require, a field class registered in a form schema, done. The honest estimate is hours, not days, and almost all of that time is verification rather than wiring. The real question is version alignment: Filament's form-component base classes, view data contracts, and asset registration have shifted across majors, and a third-party field is by definition coupled to those internals.

Technical risk.

• Framework coupling. The package's entire value is bound to Filament's field API. Major-version upgrades are the primary break vector, and they break the view rather than the data — a cheap, loud failure.
• Bus factor. 36 stars, a single maintainer, and a low opportunity score mean effectively zero community redundancy: no alternative implementation to fall back on, no crowd-sourced bug triage, no de facto support policy. Read the low score as a sustainability signal, not a quality signal.
• Small surface area cuts both ways. The package is likely a field class, a Blade view, and a stylesheet. For ~150 LOC, taking a third-party dependency is arguably the wrong trade — you are importing a maintenance obligation to avoid writing a custom field.
• Licensing is clean. MIT means fork-and-vendor is legally unencumbered with attribution. That materially de-risks the bus-factor concern.

Key questions to resolve before adoption.

1. Does it support Filament 4, and Filament 3 if you are mid-migration? Is there a CI matrix across Filament versions?
2. Feature parity with the stock Radio for every attribute your forms actually use: options from relationships/enums, validation and required, disabled/readonly, reactive (live) behavior, inline vs. stacked layout, dark mode, RTL, and SPA/navigate mode.
3. Does the persisted value match stock Radio exactly? It should — but confirm, because a serialization difference would be the one failure mode with data consequences.
4. Does it register CSS/JS through Filament's asset pipeline, and does that survive production asset publishing and caching?
5. Is the rendered markup accessible — fieldset/legend, label association, keyboard navigation? Admin panels are increasingly in accessibility audit scope.
6. Is there any stated support expectation, or is it explicitly best-effort?

Integration Approach

Stack fit. Laravel + Filament admin panel only. It has no use case outside Filament forms — not Inertia/Vue, not Livewire outside a panel, not Nova/Backpack/custom Blade. If you are on Filament, it is a drop-in; otherwise it is irrelevant, and that narrowness is a feature of the evaluation, not a flaw.

Migration path. Purely additive, with no schema or data migration. Existing forms keep the stock Radio; you swap the field class form by form. That gives a natural canary: pilot on one low-traffic resource, exercise rendering, validation, reactivity, and disabled states, then fan out. Reversal is editing the class back — switching cost is near zero, which is exactly what you want from a UI dependency.

Compatibility. Pin the package and Filament to explicit versions, and require your panel's test suite to pass on any Filament upgrade PR before merge. Because the failure mode is a broken view rather than corrupted state, this is a low-severity incompatibility class and standard version pinning is sufficient governance.

Sequencing. (1) Spike in a branch against a single resource. (2) Run the parity checklist above against the attributes your forms genuinely use — most teams find the list is short. (3) Make the buy-vs-vendor call; for a package this small, vendoring the view into your own namespace as an internal custom field is usually the better economics — same UX, no third-party surface, MIT-compatible. (4) Roll out. (5) Register it in your internal component library so the next team does not re-solve it.

Operational Impact

Maintenance. Near-zero runtime maintenance; non-trivial upgrade maintenance. Budget a small recurring task at each Filament major to verify the field renders and the view data contract holds. Operationally, treat this as "source available" rather than "supported" — with 36 stars, your team is the maintainer of last resort.

Support. GitHub issues, best-effort, no SLA, no escalation path other than your own fork. Acceptable for a UI nicety; unacceptable for anything on a critical path — and this is not on one.

Scaling. No concerns. Pure presentation: no queries, no caching, no queue work. Render cost is one Blade partial inside a form that Filament is already rendering, negligible against existing form overhead; page-weight impact is limited to whatever CSS it ships.

Failure modes.

• Filament major upgrade breaks the view — affected forms error or render blank. Blast radius is limited to forms that adopted it, and it fails visibly.
• Maintainer abandonment — package freezes but keeps working until the next Filament major. Mitigation is a fork, which MIT makes trivial.
• Accessibility regression vs. stock Radio — user-facing and potentially compliance-relevant; verify markup before broad rollout, not after.
• Asset pipeline mismatch — works in dev, unstyled in production. A classic Filament asset-publishing trap; validate in a production-like build during the pilot, not at release.

Ramp-up. Negligible for anyone who knows Filament forms — the field API shape is identical to the built-ins. The real cost is the decision (parity checklist, accessibility review, version-support verification), which is roughly half a day of a senior developer's time, not a training program.

Recommendation. Adopt only if it closes a specific UX gap the stock Radio cannot. If adopted, vendor the view into your own namespace with MIT attribution and drop the Composer dependency — the durable value here is the markup, not the distribution.