Nova Checkboxes Laravel Package

Technical Evaluation

Architecture fit. fourstacks/nova-checkboxes is a single-purpose Laravel Nova field: one thin PHP Field subclass (src/Checkboxes.php) plus a compiled Vue component that renders a checkbox group bound to a multi-value model attribute, persisted as a JSON array on an existing column. Its architectural blast radius is deliberately tiny — it touches only how operators tick options inside a Nova resource form and detail/index views. It has no bearing on customer-facing flows, APIs, background jobs, or the data model beyond that JSON payload. That makes it an internal-tooling decision, not a product capability decision, and it should be scoped and governed accordingly.

Integration feasibility. Mechanically trivial if and only if the Nova generation matches:

• composer require fourstacks/nova-checkboxes; the service provider is auto-discovered and registers the compiled asset via Nova::script() — no vendor:publish for the field itself.
• A json/text column plus protected $casts = ['features' => 'array'] on the model. Without the cast, saves throw "Array to string conversion" or the field silently re-renders unchecked — this is the single most common integration bug.
• Effort is hours, not weeks. The honest TPM framing is build or vendor, don't buy: the deliverable is a thin Field subclass plus a Vue component, and we would be buying an archived 2019 snapshot.

Technical risk. The dominant risk is vendor abandonment, not code quality. Last release 2019-12-17, repository archived, 91 stars, zero dependents. There is no upstream to patch a defect, no compatibility work for future Nova/Laravel/PHP releases, and no community canary — we would be the first to discover any failure. The compiled Vue 2 asset predates modern Nova asset pipelines and the Vue 2 → 3 shift, so on Nova 3+ the typical symptom is a blank field or a console error rather than a clean PHP exception — a debugging cost that lands on whoever is on call, not on the vendor. Secondary risks: no filter, sorting, or index-search support ships with the package, so any real usability requirement becomes custom work regardless; and whereJsonContains filtering is a full table scan without a functional/GIN index.

Key questions (to close before any commitment):

1. Which exact Nova major version are we running, and is there a funded upgrade path in the next 12–18 months? Choosing this field is effectively a decision to stay put.
2. Is Nova 4's native BooleanGroup available to us? It does the same job with the identical JSON array storage shape — meaning a native-first evaluation costs nothing and preserves a free exit.
3. Do we need filtering, sorting, or label search on these values? If yes, we are building that either way; the package gives no head start.
4. Are we prepared to own a fork forever (source vendored under MIT, added to our test coverage, pinned to our Nova version)? If not, this is a no.
5. Does procurement/compliance require a maintained-supplier story? A 2019 archive with zero dependents will not survive vendor review.
6. Where does the field live — internal, low-privilege screens where a rendering glitch is an annoyance, or anything higher-stakes? This determines whether the risk is absorbable at all.

Integration Approach

Stack fit. Constrained to Laravel Nova 2 (limited 3.x relevance) on PHP 7.x with Vue 2. If our stack is Nova 4+/Laravel 9+/PHP 8+, the package is a non-starter on asset-pipeline grounds alone, and BooleanGroup is the correct target.

Migration path (decision order matters).

The critical planning fact is that the data shape is portable and reversible: selected keys persist as a JSON array, exactly what BooleanGroup writes. That means the storage decision is cheap and the dependency decision is not — so take the storage pattern, decline the dependency, and keep the exit open.

Compatibility. Pin laravel/nova and the package together in composer.json if we vendor it; check the laravel/nova constraint in the repo composer.json before installing anything. Use stable string keys in options() — a plain list (['Newsletter', 'Updates']) stores integers 0,1, so reordering or inserting an option silently reinterprets existing records. This is a data-integrity constraint, not a style preference, and should be enforced in code review. Centralise the option list in one shared class (e.g. app/Support/Features.php) so form, validation, and filters cannot drift.

Sequencing.

1. Confirm Nova version and BooleanGroup availability. If native fits, stop — no package, no dependency, no further work.
2. Write the storage decision down: JSON column, $casts = ['array'], string slugs as keys. This survives whichever rendering option we choose.
3. If a fork is genuinely required: vendor the field class and Vue components, add them to test coverage, pin Nova, and rebuild dist/js/field.js (it is a committed build — a fork that skips the rebuild ships stale JS).
4. Run php artisan nova:publish and hard-refresh; verify the field renders and round-trips a save on staging, not production.
5. Layer the custom work we will need anyway: a filter using whereJsonContains, and a displayUsing()/computed Text field if index presentation needs to be richer than plain labels.
6. Only then roll to internal, low-privilege resources first.

Operational Impact

Maintenance. If adopted as a dependency, maintenance is zero by the vendor and total for us — an archived repo accepts no fixes, so every defect becomes an internal ticket with no upstream answer. If forked, we own roughly a few hundred lines of PHP and Vue, plus a build step for dist/js/field.js, permanently. Neither outcome is large; both are permanent. Budget the fork at well under a day including tests; budget the ownership as an ongoing line item under internal tooling maintenance.

Support. There is no support, no security patching, no SLA, and no issue triage. This is a governance finding, not a technical one: the component executes inside our authenticated admin surface, so an unpatched defect has a privileged attack surface and no patch route. That single sentence should decide the dependency question for most organisations.

Scaling. Three limits to plan around:

• Filtering: no filter ships. Write one with whereJsonContains (MySQL 5.7+/MariaDB 10.2+/Postgres jsonb) — not LIKE, which produces substring false positives (beta matching beta_access). On SQLite, json_each or LIKE '%"key"%' with quotes included.
• Indexes: whereJsonContains is a full scan on a large table unless backed by a functional/generated-column index (MySQL 8) or a GIN index on jsonb. Decide this before the table grows, not after.
• Search: Nova's index search will not traverse the JSON for label text. If users need it, add a scopeSearch or a generated column — again, custom work with or without the package.

Failure modes.

Ramp-up. Low, and bounded by reading the source rather than documentation: start at src/Checkboxes.php (field class, options()/resolve logic), then resources/js/components/FormField.vue and IndexField.vue to see exactly how the value is shaped on the wire. Because there are zero dependents and 91 stars, there will be no upstream answers when it breaks — assume the team reads the code. A competent Laravel engineer is productive in half a day to a day, including the fork, one filter, and basic tests.

TPM recommendation. Do not adopt fourstacks/nova-checkboxes as a Composer dependency. Take the storage pattern (JSON array, string slugs, array cast) and the worked example, and implement the rendering with Nova's native BooleanGroup where available. Where it is not, vendor the MIT source into our codebase under test coverage as an internal-tooling line item — never as a roadmap initiative.