Nova Checkboxes Laravel Package

Product Decisions This Supports

• Scoping internal admin tooling, not product capability. This package only changes how an operator ticks multiple options on a Nova resource form. It does not touch customer-facing flows, APIs, or background jobs beyond a JSON payload on an existing column. It belongs in "internal tooling" conversations and should never appear in a product capability or customer-facing roadmap review.

• A clean build-vs-buy reference case. The entire deliverable is one thin Field subclass plus a Vue component that renders checkboxes and persists an array — hours of work, not weeks. When the "buy" side is an archived 2019 snapshot, the honest framing for stakeholders is build or vendor, don't buy.

• A multi-value attribute modelling decision. It answers a real product-data question: should this record hold several independent flags (notification channels, feature entitlements, permission sets, categories)? If yes, the JSON-array shape this field establishes is the right one — and it matches Nova 4's native BooleanGroup, which makes the decision portable and reversible.

• Vendor-risk and maintenance-burden governance. 91 stars, zero dependents, last release December 2019, repository archived. That is a governance input, not a technical one: adopting it means permanently owning a component that executes inside our authenticated admin surface with no upstream to patch it.

• Upgrade-path planning. Anything touching Nova pins us to a Nova generation. Choosing this field effectively says "we are staying on Nova 2/3 for the foreseeable future" — better decided explicitly than by accident.

• Roadmap hygiene. A composite score around 1.3 and an opportunity score around 18 describe a cosmetic admin convenience. It is at most a line item inside "internal tooling maintenance," and realistically one we can retire.

When to Consider This Package

Consider it — and only as source to vendor or copy, not as a Composer dependency — when all of the following hold:

• You are already running Laravel Nova 2 or 3 on PHP 7.x, with no near-term upgrade planned, and you specifically need a checkbox group in a Nova resource form (not a select, tags, or relationship field).
• You are willing to fork the MIT-licensed code into your own codebase and own it indefinitely: no upstream fixes, no issue triage, no future compatibility work.
• The field lives on internal, low-privilege screens where a rendering glitch is an annoyance rather than an incident.
• You can absorb the two classic failure modes: the JSON column plus $casts = ['array'] requirement (without it, saves throw "Array to string conversion" or the field re-renders unchecked), and stable string keys in options() so reordering options never silently reinterprets stored records.

Look elsewhere when:

• You are on Nova 4+ / Laravel 9+ / PHP 8+. The committed Vue build predates modern Nova asset pipelines; expect a blank field or a console error rather than a clean PHP exception. Nova 4 ships BooleanGroup, which does the same job with the same JSON storage shape — migrating is essentially BooleanGroup::make('Features')->options(...) and dropping the package, with no data transformation required. That cheap exit is the strongest argument for evaluating the native field first.
• You need support, security patching, or an SLA — an archived repo cannot supply any of these.
• You need filtering, sorting, index search, or richer index rendering of the stored values. No filter ships with the package, and Nova's index search won't traverse JSON for label text; these are custom builds either way. If you build a filter, use whereJsonContains (MySQL 5.7+/MariaDB 10.2+/Postgres jsonb) rather than LIKE, or you will get substring false positives — and index the generated/functional column before the table grows.
• Procurement or compliance requires a maintained-supplier story. A 2019 archive with zero dependents will not survive vendor review.

How to Pitch It (Stakeholders)

To executives: This is a small convenience add-on for our internal admin panel — a nicer way for staff to tick several options on a record. It is not a product capability, and customers will never see it. It is free (MIT) and genuinely low-risk to try, but the project is archived and unmaintained since 2019, so we should not take it on as a dependency we rely on. Current Nova ships an equivalent field natively, and where it doesn't, this is a few hours of in-house work. Recommendation: do not adopt. The cost of owning it as a dependency exceeds the cost of building it.

To engineering: Treat fourstacks/nova-checkboxes as reference source, not a package. If a checkbox-group field is genuinely needed and native BooleanGroup doesn't fit, vendor the field class and Vue component into our codebase under MIT, add them to our test coverage, and pin them to the Nova version we run. Do not add it to composer.json on any project on a supported Nova/Laravel upgrade path — we would be inheriting an unmaintained component inside an authenticated admin surface with no patch route. Practical notes for whoever picks it up: read src/Checkboxes.php and the FormField.vue / IndexField.vue components first; dist/js/field.js is a committed build, so any fork needs a rebuild plus php artisan nova:publish and a hard refresh; normalise reads with (array) $model->features because empty state can come back as null, [], or ''; and keep the option list in one shared class so form, validation, and filters never drift. Estimate the fork at well under a day including tests.