Nova Switcher Laravel Package

Product Decisions This Supports

• Admin UX polish, not product surface. This package only changes how a boolean attribute renders inside a Laravel Nova resource — a switch instead of a checkbox/dropdown. It supports internal operator decisions (“can an ops user flip is_active, is_featured, published, or an internal flag in one click?”). It does not touch customer-facing product, pricing, data model, or API contracts.
• Build vs. buy vs. configure — a three-way call. The PM decision is: use Nova’s first-party Boolean field (zero cost), spend roughly half a day generating a small custom field we own via php artisan nova:field, or add this dependency. Given the package is archived, has 12 stars, zero dependents, and a last release of November 2023, adding it as a dependency is the weakest option on total cost of ownership.
• Roadmap impact: negligible — treat as backlog hygiene. This is hours of effort, not a quarter’s planning slot. It should not displace customer-facing work, and it should not appear on a roadmap as a deliverable. The right home is an admin-tooling backlog item owned by the platform/internal-tools team.
• Use cases it maps to: back-office moderation queues, publishing/visibility state, subscription pause/resume, feature-flag administration, soft-delete/restore toggles. All internal, low blast radius, reversible attribute flips.
• Demand validation signal. Low adoption plus an archived repository says the need is either already satisfied by Nova core or too niche to sustain a package. That is useful evidence the next time an engineer or designer asks for “nicer toggles” — the answer is probably a platform default, not a new dependency. A 23.77 opportunity score reinforces that the leverage here is small.
• Reference value only. If we do need bespoke ergonomics, the source is a reasonable pattern reference for scaffolding an owned field (a Vue component plus a PHP field class). That is a learning artifact, not a procurement decision, and carries no ongoing support obligation.
• Risk-pricing input. The absence of dependents means no public evidence anyone has field-tested edge cases — no signal on accessibility, keyboard semantics, localization, or null-state handling. That is a direct input to where we permit this control (internal flags) versus where we forbid it (billing, entitlements, permissions).

When to Consider This Package

Consider it narrowly when:

• You already run Laravel Nova and have boolean-heavy resources operators edit dozens of times a day — the ergonomic win is real, if small.
• You are on an older Nova version where the core Boolean field does not render an inline toggle in index views, and a Nova upgrade is genuinely out of scope this cycle.
• The surface is strictly internal, with no security, compliance, or accessibility obligations attached to the control.
• You are prepared to vendor or fork the code rather than depend on it, since upstream is archived and will ship no fixes, no Nova-major compatibility work, and no security patches. Pin the exact version and attach a named owner.

Look elsewhere when:

• You are on Nova 4 or 5 — use the built-in Boolean field, or generate a short owned field with nova:field. Zero dependency, zero maintenance, and it survives the next Nova major because we control it.
• You are not on Nova at all — Filament ships ToggleColumn/Toggle first-class; Livewire and Backpack have equivalents. This package is not portable across admin stacks.
• The toggle would be customer-facing, or where an accidental state change is expensive (billing, entitlements, permissions, publish-immediately actions). An archived, single-maintainer package with zero dependents has no field-proven edge-case coverage.
• You need accessibility conformance, localization, or a confirmation guard before destructive toggles — nothing in the package profile suggests any of that was validated, and the extension surface is the plain Nova field API, not package options.
• Your team has a policy against unmaintained dependencies. This package fails that test outright and generates “abandoned package” noise in Composer audit output, which erodes signal on genuine dependency risks.

The honest default: on any new Nova work, reach for Laravel\Nova\Fields\Boolean first, nova:field second, and this package essentially never.

How to Pitch It (Stakeholders)

For executives: This is a small cosmetic add-on for our internal admin panel. It turns boolean on/off attributes into single-click toggle switches so operations staff save a few seconds per edit. There is no customer-facing impact and no revenue impact. The vendor is archived and effectively unmaintained, so I do not recommend adding it to our dependency list — the current version of our admin framework already provides this behavior natively. Net recommendation: decline adoption, keep the capability parked in admin-tooling backlog, and revisit only if the ops team explicitly asks for it. Cost of the recommended path is effectively zero.

For engineering: The capability is now native to current Nova releases via the Boolean field, so the package is largely redundant. Adopting it means inheriting an archived repo, zero dependents as a compatibility signal, and no verified support for current Nova majors — the 2023-11-01 release sits in the Nova 4.x era, and custom field components have historically broken across Nova majors due to Vue and asset-pipeline changes. The typical first failure is silent: a blank cell and console errors, not a stack trace. Two acceptable paths: (1) use the framework default, or (2) invest under half a day in a purpose-built field we own under app/Nova/Fields (or a private nova-components package), compiled with our own Nova tooling, with provenance/attribution recorded in the repo. If we genuinely want the exact ergonomics, read its source as a pattern and reimplement — do not install it. If someone overrides this and installs anyway: pin the exact version, confirm the license permits vendoring before copying source, add a “regression-check the switcher field” line to the Nova upgrade checklist, and add a deliberate config.audit.abandoned ignore rather than living with the noise. Budget: under half a day either way.