Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Nova Checkboxes Field Laravel Package

idez/nova-checkboxes-field

A Laravel Nova field package that adds a checkbox group input to resource forms, letting users select and store multiple options at once. Drop-in checkboxes field with native Nova styling and minimal setup for multi-select values.

View on GitHub
Deep Wiki
Context7

Product Decisions This Supports

  • Build vs. buy for admin surface area. The realistic comparison is not "package vs. nothing" — it's "free MIT field vs. 1–2 engineer-days to scaffold a custom Nova field plus indefinite ownership of the Vue build." For a single resource, buying wins on cost. But with 5 stars, 0 dependents, and a single maintainer, "buy" is really "adopt now, plan to fork later." Price the fork into the decision up front; don't let it surface in month three as a surprise.
  • Feature scoping for multi-value inputs. Use cases this unblocks cleanly: per-user notification/channel preferences, interest/tag/category selection on records, ops-level feature-flag or segment assignment, and — via the 1.1.0 grouped mode — an internal permissions matrix where a flat multi-select feels wrong and a stacked checklist is the obvious affordance. Each of these is a small admin feature that would otherwise get deferred or half-built.
  • Internal-tooling velocity vs. platform investment. This is a form control. It doesn't unlock a product capability; it removes friction from standing up back-office tooling. The decision it informs is "how fast can we ship the admin surface for this feature," not "what should we build next." Treat it as an accelerator for internal tools, not a roadmap item.
  • Grouped checkboxes as a permission-grid play. The 1.1.0 grouped mode is the only genuinely differentiated capability — Nova's built-in BooleanGroup cannot group, and Select::multiple() can't render a stacked checklist. If your requirement is literally "a permission matrix with headings," this package closes a real gap that the built-ins don't. If your "groups" are just categories, they aren't worth the dependency.
  • Roadmap signal / dependency risk weighting. Headline feature shipped June 2022 and nothing since. No test suite, no config file, no extension points (no select-all, no max-selection cap, no ordering hook). Any roadmap item that assumes this package will grow with Nova 4.30+/Nova 5 is mispriced. Factor in that a Vue 2/3 mismatch installs cleanly and then renders a blank field at runtime — a silent failure mode that costs debugging time, not install time.

When to Consider This Package

Adopt when all of these are true:

  • You are on a Nova version whose laravel/nova constraint and Vue build actually match this June-2022 bundle — verified in composer.json and package.json, not assumed from a successful composer require.
  • The requirement is specifically a stacked, grouped checkbox list (the grouped 1.1.0 feature) or a straightforward flat multi-select checkbox group where a Select::multiple() dropdown would be poor UX.
  • The value maps to a single JSON column with an array cast — tags, channels, categories, permissions. Not a relational belongsToMany.
  • Your team is willing to own a local fork (nova-components/checkboxes/) if the package stalls. MIT license makes this legitimate and low-friction.
  • It's one or two resources, not a platform-wide dependency.

Look elsewhere when:

  • Nova's built-ins cover it. BooleanGroup (stores {"key": true}, renders toggle pills) or Select::make()->multiple()->options(...) handle most checkbox use cases with zero maintenance. Reach for the package only when the grouped-list UI is the actual requirement.
  • You need relational data. If selections should be a belongsToMany, a native relationship field with ->multiple() is less code and no unmaintained dependency. Bridging via fillUsing/resolveUsing works but is a worse trade.
  • You need behavior the field doesn't offer — select-all toggles, max-selection limits, ordering hooks, custom authorization. There are no extension points; the answer is "fork it," so decide that deliberately rather than discovering it mid-sprint.
  • Search and filtering are core requirements. searchable() doesn't work on JSON columns (false positives across keys), SQLite doesn't support whereJsonContains, and integer keys round-trip as strings. If ops users will filter heavily on this field, budget for a model scope or a denormalized text column.
  • You're on Nova 4.30+ or Nova 5 and can't tolerate a compatibility audit. A blank index cell or a field that renders but never persists is a Vue 2/3 base-class mismatch, not your migration. Don't schedule this on a critical path.

Non-negotiable pre-work if you adopt: confirm the stored value shape on day one — flat array of leaf keys (['posts.create','users.ban']) vs. nested object mirroring group structure. Everything downstream (validation allow-lists, whereJsonContains filters, label lookups, accessors) depends on that single answer. Also assert exact payloads in a round-trip feature test, not just assertOk() — group labels leaking into stored values is an easy, silent bug with a naive nested v-model.

How to Pitch It (Stakeholders)

For executives: This is a free, MIT-licensed UI component for our admin panel that adds a clean multi-select checkbox group — the natural affordance for tags, notification channels, categories, and internal permission grids. It's a small, reversible internal-tooling bet, not a platform commitment. The cost is roughly zero against a 1–2 day build; the risk is that the package hasn't shipped since mid-2022, so we treat it as code we adopt and own rather than a vendor we depend on. Worst case, we vendor a copy into our repo (which the license permits) and maintain it ourselves — a contained, well-understood outcome. Recommendation: adopt for one or two back-office resources now, contingent on a half-day compatibility check against our Nova/Vue version.

For engineering: Install is a single composer require with no config publish step. Before building on it, do two things: (1) audit composer.json's laravel/nova constraint and package.json's Vue version — a Vue 2 field installs cleanly on Nova 4+ and then renders blank at runtime, so a console check for Failed to mount component is mandatory; (2) read resources/js/components/FormField.vue and the network tab on save to determine whether grouped mode persists a flat leaf-key array or a nested group-shaped object. That determines the migration's column type, the model cast, whether whereJsonContains works for filters, and whether your validation allow-list must be the flattened leaf keys. Expect to supply what the package doesn't: element-level validation (field rules apply to the attribute, not its elements), null-safe normalization on create, index/detail display formatting, authorization via policy in the resource's fields(), and a round-trip feature test asserting the exact stored array — there's no test suite to lean on. If grouped mode is the reason we're adopting, eyeball its Vue template for Vue 2 syntax before trusting it; that's the newest and least-exercised code in the bundle. Long-term path if it stalls: copy src/ and resources/js/ into nova-components/checkboxes/, rebuild, and depend on the local version.

Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
novasa/laravel-language-center
opencage/geocode
adolfoholzer/parameters
livenetworks/ln-starter
shitoudev/permissionmanager
johannesclimacus/laravel-tui
hocvt/seotools
vitalybaev/sypexgeo
amphibee/themosis-ignition
gito-me/fast-excel
frankyso/laravel-ipaymu
geolize-studio/laravel-chile
boomerangui/chat
cgv/localized-resource
noith/settings
kda/laravel-package
kda/filament-dynamic-navigation
bypersoft/signbox
pairus/product-data
fayne/laravel-filament-cms-core