Nova Toggle Laravel Package

Product Decisions This Supports

• Back-office UX investment, explicitly not roadmap scope. This package answers one narrow question: should boolean attributes in Laravel Nova ship as default checkboxes, or as toggle switches that ops and support staff can scan and flip with confidence? For internal tools where staff scan lists of flags (is_active, published, featured, verified), it is a small, measurable reduction in mis-clicks and cognitive load across index, detail, create, and update surfaces — but it does not touch customer experience, revenue, or the product roadmap. Judge it as admin polish, not as product capability.
• Build vs. buy for presentation-layer work. A toggle is a single Vue field sitting on top of Nova's built-in Boolean field. The PM decision is whether to spend a sprint ticket on a custom field or adopt a five-minute dependency. Cost-of-effort favors "buy," but the effort is small enough that "build inline" is a legitimate answer — especially given the 2022 last release, zero dependents, single maintainer, and 85 stars. Treat this as code you may inherit, not a dependency you can rely on for support.
• Where we spend admin polish. Adopting it signals the admin surface is treated as a product. Small cumulative UX wins on screens that ops and support live in daily compound into fewer mistakes on production-adjacent switches.
• Safety and permissions around lifecycle flips. Publish/unpublish, feature-flag, and account-state toggles depend on a clear, low-friction control. Choosing this field shapes how safely non-engineers flip those states — but the field is a view layer only. Audit trails, permission gates, and optimistic rollback belong in the model or observer, not in the toggle. Any decision note should say this out loud so nobody assumes the switch enforces policy.
• Whether inline index editing is in scope. The package's stated value is flipping a flag without opening a form (exceptOnForms() on the index). If our team never edits from index listings, the marginal benefit over a plain checkbox drops sharply and the whole adoption case weakens. This is the single biggest deciding input.
• A forcing function for dependency policy. This is a textbook "small, single-maintainer UI dependency." Deciding it deliberately — pin the exact version, name an owner, pre-authorize a fork path — turns the next such decision into a ten-minute call instead of a fresh debate. The reusable output here is the policy, not the field.
• Roadmap weighting (correctly, low). With ~85 stars, zero dependents, a 2022 release, and a low opportunity score, this is a tactical "adopt and move on" utility — not a platform bet, not a strategic dependency, and explicitly not something that should block a Nova major-version upgrade.

When to Consider This Package

Adopt when:

• You are already running Laravel Nova. The package delivers zero value outside it — Nova is a paid, first-party admin panel, so the addressable audience is a subset of Laravel teams. If Nova isn't in the stack, close the ticket.
• You have many boolean attributes across Nova resources and want one consistent, scannable switch control rather than per-resource bespoke styling or a hand-rolled Vue field.
• You are on a confirmed-compatible Nova major. The field was shipped against Nova 4-era tooling; the documented failure mode is Nova 5's Vue 3 / Vite pipeline. "Confirmed" means we piloted the package on one non-critical resource in staging and verified all four surfaces plus inline index editing — not that the README looked fine.
• Ops or support staff genuinely flip flags from list views. This is the value case. If the workflow is "open record, edit form, save," a checkbox is adequate.
• The change is reversible and bounded. The rollout is a mechanical Boolean::make() → Toggle::make() swap with no migration, no schema change, and no data remediation. Rollback is reverting an import and a make() call — or flipping a config flag if you route field creation through a small factory.

Look elsewhere (or keep Boolean) when:

• You are on Nova 5 without a verified pilot. A dist/ compiled for Vue 2 mounted into a Vue 3 Nova produces an empty field with no server-side error — clean logs, intact data, broken control. That is the worst failure shape for an internal tool.
• The attribute is nullable or tri-state. nullable() with a distinct "unset" state is a checkbox-with-indeterminate problem, not a two-position switch problem. Keep Boolean until null round-tripping is explicitly tested.
• You use non-standard trueValue() / falseValue() — 'yes'/'no', 1/0 against a string column. Verify inheritance before assuming it works; if it doesn't, that's a fork, not an adoption.
• You need a vendor with a support commitment or an SLA. Single maintainer, no release since 2022, community-only support (Nova's paid support does not extend to third-party fields), zero dependents.
• You already maintain an internal Nova field package. Promote this PHP class and Vue component into acme/nova-fields instead — the endgame either way.
• The flag is lifecycle-critical. A misplaced click on an index listing now flips is_published in production. For those, use onlyOnDetail(), add a confirmation affordance, and make sure the model fires an attributable event.
• You're choosing a customer-facing control. This is an admin panel field, not a design-system component.

How to Pitch It (Stakeholders)

To executives — the one-liner: This is a small, reversible polish item for our internal admin panel. It replaces plain on/off checkboxes with a standard toggle switch on the screens our ops and support teams use daily, which reduces mis-clicks on production-adjacent flags like "published," "active," and "featured." It is a five-minute, zero-migration change with a one-line rollback, no customer-facing impact, and no schema risk. It should not appear on the roadmap as a feature — it's maintenance-grade work.

What leadership should know about the risk: This is a single-maintainer open-source utility with no release since 2022 and no commercial support. We are not buying a vendor relationship. The mitigation is cheap and must be pre-agreed: pin the exact version, record the validated Nova version in the repo, name an owner, and pre-authorize a fork into our own internal field package if Nova's next major breaks it. At roughly one PHP class, one Vue component, and one compiled asset, forking is hours of work, not weeks. The honest framing is "we are adopting code we may inherit," not "we are taking on a dependency."

To engineering — the ask, in order: Confirm the Nova major version before installing. Read src/Toggle.php to confirm it extends Boolean rather than reimplementing it, and confirm inherited default(), rules(), nullable(), and fillUsing() behave identically. Check whether dist/ is committed and whether it targets Vue 2 or Vue 3 — that one answer decides adopt-versus-fork. Treat an absent or wildcarded laravel/nova constraint in the package's composer.json as a red flag, not a convenience.

Execution plan we're asking for: Inventory and classify every Boolean::make() in app/Nova. Pilot the swap on one non-critical resource in staging — a settings page or taxonomy table, never users.is_active first. Verify the index cell, detail view, create form, update form, and inline index editing. Confirm default()/rules() parity with Boolean. Then roll out per resource under normal PR review. Register the package on the Nova major-upgrade checklist with a named owner. Route field creation through a small factory class so labels and colors stay consistent and there is a one-line config kill switch back to plain checkboxes.

What we will not catch with tests: Server-side tests can prove persistence and policy, not rendering. A broken Vue component renders as a blank field, a raw input, or an empty cell with a 200 response and no server-side error. Visual QA on the pilot page and on any later Nova upgrade is a required release-checklist step, not optional diligence. Keep a written inventory of which fields are now toggles so that QA step is a bounded checklist rather than a hunt.

The decision we want recorded: Adopt narrowly, pin exactly, pilot first, fork pre-authorized. The deliverable is a reusable policy for small single-maintainer UI dependencies as much as it is a nicer switch.