Group Checkbox Laravel Package

Technical Evaluation

Architecture fit. This is a Nova 4 field package — a presentation-layer extension consisting of a PHP Field subclass plus a compiled Vue component. It couples only to Nova's field API, not to your domain model, which makes it architecturally cheap to adopt and equally cheap to remove. That is the main point in its favor. The flip side of that thinness: it does not solve persistence. Whatever the grouped checkbox state lands in — a JSON column, a pivot table, or a serialized attribute — casting, validation, authorization, and index/detail formatting remain your application's responsibility.

Integration feasibility. Straightforward in principle. Composer install (likely from a VCS repository rather than Packagist, given the zero footprint), register the field in the target Resource::fields(), publish assets via nova:publish. Realistic effort is measured in hours for a Nova-experienced engineer, not days. The unknowns are procedural, not conceptual: whether dist/js is committed or must be built, whether the namespace/autoload matches the package name, and whether the declared Nova constraint is real or aspirational.

Technical risk. High, and concentrated in dependency health rather than code complexity. Zero stars, zero dependents, single author, no visible CI or test suite, no issue history — there is no signal that this survives a Nova minor release. Nova itself is closed-source and commercially licensed, so you cannot patch the host when a field breaks; your only remedies are forking the package or replacing the field. Any adoption should assume you are taking ownership of the code on day one.

Key questions.

• What does this provide that Nova's native BooleanGroup field does not? (Grouping, multi-column layout, per-group labeling, pivot support?) If the answer is cosmetic, the build-vs-adopt math changes materially.
• What is the storage contract — single JSON attribute, pivot sync, or both? Is it documented or must it be reverse-engineered from the Vue component?
• Are compiled assets committed, and is the front-end toolchain compatible with Nova 4's Vite/Vue 3 setup?
• What Nova, Laravel, and PHP versions are actually declared, and were they tested or merely asserted?
• License terms and author responsiveness — is there any path to upstream fixes?
• Does the field respect Nova's authorization and validation pipeline, or does it bypass it?

Integration Approach

Stack fit. Only viable on Nova 4 (Vue 3 / Inertia) with Laravel 9+ and PHP 8.1+. On Nova 3 the field API and Vue 2 runtime are incompatible — this is a hard no, not a port. If the team is not already a licensed Nova shop, the package is irrelevant; the buy decision is really about Nova, not about this field.

Migration path. Treat it as a vendored dependency, not a community package. Concretely: fork to an internal repository (or a path/VCS repository pinned to a commit SHA), install from the fork, publish assets, register on one resource, and add an application-level feature test that exercises the Nova update endpoint and asserts the persisted state. Never consume a floating branch.

Compatibility. Pin the exact commit and record the Nova version in composer.json. Add the fork to whatever dependency-update automation exists, and — more importantly — add a contract test that runs against Nova upgrades in staging so a broken field surfaces in CI rather than in production. If the package's asset build is not reproducible, budget for rebuilding the Vue component yourself.

Sequencing.

1. Spike: install in a scratch Nova resource, confirm render, save, index, and detail views.
2. Compare against BooleanGroup + a custom accessor; document why the package wins or loses.
3. Validate on the real resource shape, including the persistence path and any existing data.
4. Fork, pin, and add the regression test.
5. Add the asset publish step to the deploy pipeline before rollout.

A parallel track worth running: prototyping the field in-house. It is one PHP class and one Vue single-file component — often less total effort than absorbing an unmaintained dependency, and it removes the fork obligation entirely.

Operational Impact

Maintenance. You will own this. The surface is small — a field class and a component — so the steady-state cost is low, but the front-end toolchain (Nova's build conventions, asset publishing) is where maintenance time actually goes. Budget a named owner for the fork, or accept that it silently rots.

Support. Effectively none upstream: no documentation, no maintainer SLA, no issue history to mine for known failure modes. Internal runbook and inline documentation are prerequisites, not nice-to-haves. This is the largest hidden cost of adoption.

Scaling. Not a performance concern. This is admin-panel UI serving low request volume; it will never be a bottleneck. The scaling question is organizational: how many resources adopt the field, and whether behavior stays consistent across them. Standardize on one usage pattern and document it.

Failure modes.

• Silent save failures — checkbox state not persisted on update, discovered by users rather than tests.
• Post-upgrade render breakage on a Nova minor bump, with no upstream fix available.
• Asset 404 after deploy when the publish step is dropped from CI.
• Orphaned keys in JSON storage when the option list changes, leaving stale values in existing records.
• Authorization or validation gaps if the field bypasses Nova's policy and rules pipeline.
• Abandonment: repository archived or the author disappears, which is the base case given zero dependents.

Ramp-up. Low for anyone fluent in Nova — the field is declarative and the API is small. The genuine ramp is on the JS build toolchain for whoever inherits the fork, and on the on-call engineer who has to diagnose a persistence bug with no upstream reference. Given the 30.56 opportunity score and the absence of any adoption signal, the recommendation is: adopt only behind an internal fork with a regression test, and only if the spike proves it does something BooleanGroup cannot. Otherwise, build the field in-house — the effort is comparable and the ownership is clearer.