Boolean Group Laravel Package

Technical Evaluation

Architecture fit. marshmallow/boolean-group is a Laravel Nova field — a presentation-layer extension for the admin panel, not application runtime code. It has zero architectural surface area in the product itself: no service provider side effects beyond Nova asset registration, no middleware, no database migrations implied by the package. That makes it architecturally low-risk and strategically narrow. It is only relevant if the team already owns a Nova license and runs Nova in production. If Nova is not in the stack, this package is a non-starter regardless of quality.

The implied use case — collapsing a set of related boolean flags (permissions, feature toggles, notification preferences, per-tenant capabilities) into one grouped control on a Nova form — is a genuine papercut in Nova. Nova's native Boolean field renders one toggle per attribute, so a resource with 8–12 flags produces a long, cognitively noisy form. The value proposition is UX consolidation for internal operators, which is real but modest.

Integration feasibility. Installation is a composer require plus field usage in a fields() method, contingent on the package's Nova major-version support. v1.2.0 materially improves this: Nova 5 support was added via a merged community PR, so the package is no longer gated to Nova 4 (Vue 2). Teams on current Nova can now evaluate adoption rather than defaulting to fork-and-port.

The remaining feasibility question is not installation but storage semantics: does the field resolve booleans from discrete columns, or from a single JSON blob? That choice determines casting, validation, indexing, and whether the values are queryable in Nova filters and metrics. This must be verified from source before any commitment.

Technical risk. Still elevated relative to the value delivered, but the profile has shifted — one High risk is retired, and a weak-positive governance signal has appeared:

Key questions for the maintainer / source audit.

1. Does composer.json now declare nova ^4.0|^5.0, or ^5.0 only? Is Nova 4 still supported, and is that a breaking change for existing v1.1.0 users?
2. Does v1.2.0 ship separate compiled assets per Nova major, or a single dist/ against one Vue version? This is the crux of whether Nova 5 support is real or a constraint bump.
3. Does the field write to individual model columns or a single JSON column? What cast does it assume?
4. Are resolveUsing / fillUsing overridable, and does it respect Nova's rules() and nullable semantics?
5. Does it support sortable() / filterable() — i.e., are the underlying values queryable, or is this display-only?
6. Is there a compiled dist/ asset committed, or must the host app run npm run nova:install?
7. What is the license, and is forking explicitly acceptable?
8. Are there tests, and do they exercise the hydrate/fill round trip — on both Nova majors, if both are claimed?

Integration Approach

Stack fit. Compatible only with Laravel + Nova stacks. Requires PHP 8.1+ and a Nova license whose major version matches the package's declared constraint. As of v1.2.0, Nova 5 is in scope, which removes the previously likely fork-and-port path for teams on current Nova. The build-vs-adopt calculus should still be run explicitly: a grouped-boolean field is roughly 1–2 engineer-days of work (one PHP field class, one Vue component, tests), so adoption is only obviously correct if the audit is clean. The arrival of Nova 5 support tilts the decision toward evaluation, not automatically toward adoption.

Recommended integration posture: vendor, don't depend. The Nova 5 release does not change this. There are still zero dependents and no release cadence — you are one maintainer's attention away from a frozen repo, and Nova 6 will arrive. Instead:

1. Install into a spike branch and exercise it against a real resource with a representative flag set — on your actual Nova major.
2. If it behaves, copy the field class and the Vue component for your Nova version into app/Nova/Fields/ (or a first-party acme/nova-fields internal package) and take ownership of the code. Do not vendor both branches; take the one you run.
3. Uninstall the upstream package. This removes abandonment and supply-chain risk entirely at the cost of ~half a day of curation.

Migration path. No data migration is needed if the field maps to existing boolean columns. If it assumes a JSON column, that is a migration and a schema decision — evaluate whether JSON storage is acceptable given the team's query and reporting needs, or whether discrete columns are required. Do not let a UI convenience drive the persistence model.

There is also an upgrade path consideration that did not exist before: teams already on v1.1.0 should confirm whether v1.2.0 is additive (Nova 4 + 5) or breaking (Nova 5 only). If breaking, pin ^1.1 until you've validated on your Nova version — do not float the constraint.

Compatibility and sequencing.

• Gate 1 — Spike (0.5 day): install in a branch on your Nova major, render on two resources, verify create/update/detail views and that the round trip persists.
• Gate 2 — Audit (0.5 day): read the field class and Vue component; confirm the version constraint, whether Nova 5 support includes a rebuilt component, fill semantics, validation passthrough, and asset build story.
• Gate 3 — Decide (build vs. vendor vs. reject): if the audit surfaces more than a day of remediation, build in-house.
• Gate 4 — Rollout: apply to the one or two resources with the worst flag sprawl; keep the native Boolean fields available behind a panel/canSee check for one release as a fallback.
• Gate 5 — Generalize: only after two sprints of stable operator use, standardize it as the house pattern and document it.

Scope discipline. This is an internal-tooling improvement. It should not consume a roadmap slot, should not block a release, and should be timeboxed at two days total. If it exceeds that, the in-house build wins by default. The Nova 5 release is a reason to start the spike if you previously deferred it, not a reason to expand the timebox.

Operational Impact

Maintenance. Effectively 100% — the team becomes the maintainer the moment it is used, whether or not the code is vendored in. v1.2.0 slightly improves the upstream story (someone other than the author has touched it and the maintainer merged it), but does not change the local obligation. Budget a half-day per Nova major upgrade to verify the Vue component against the new Nova asset pipeline — that estimate stands. Note that Nova 5 was the specific upgrade that historically broke these fields; it is now handled, which retires the most imminent known maintenance event and pushes the next one out to Nova 6.

Support. No vendor, no SLA, no issue-triage expectation. Escalation path for an operator-facing bug is "the engineer who integrated it reads the source." That is acceptable for admin tooling and unacceptable for anything customer-facing — which this is not. The v1.2.0 PR does suggest the maintainer will accept patches, which is a useful escape hatch: if you find a defect, upstreaming it is plausible.

Scaling. Negligible. The field renders in the Nova admin only, so it has no effect on request latency, queue throughput, or public traffic. The only scaling consideration is query behavior: if the field hydrates a relation or a JSON column, confirm it isn't triggering N+1 queries on Nova index views with large per-page counts. Test against a resource with a few thousand rows and perPage at 100. Unchanged by the release.

Failure modes to watch.

• Silent no-op on save: the field renders but fill() doesn't persist because the attribute name or cast doesn't match. Highest-probability failure; requires an explicit create-and-reload test, not just a visual check.
• Asset build mismatch: compiled JS targets a different Nova/Vue version; form renders blank or throws in console with no server-side error. Post-v1.2.0 this risk is now version-specific — verify the asset you pull matches Nova 4 or Nova 5, not just the package version. A single dist/ serving both majors is a red flag.
• Dual-major regression: if v1.2.0 refactored the component to reach Nova 5, Nova 4 behavior may have regressed unnoticed. If you are on Nova 4, re-run the round-trip test rather than assuming the patch is inert.
• JSON decode failure: malformed or legacy values in a JSON column cause the component to render empty, and a subsequent save can overwrite real data with defaults. Mitigate with a read-only detail view before enabling edit.
• Validation bypass: group fields often skip individual-attribute rules(); authorization on individual flags must still be enforced server-side in policies, not just hidden in the UI.
• Mass-assignment interaction: ensure the grouped attribute names remain in $fillable / policy checks where relevant.

Ramp-up. Low for engineers already fluent in Nova custom fields — the pattern is well-trodden and the codebase is small enough to read in an hour. Non-Nova engineers should not touch it. Operational documentation burden is one short internal note covering: which resources use it, the storage convention (columns vs. JSON), the Nova major the vendored copy targets, and the "reload after save" verification step for QA.