Inline Boolean Field Update Laravel Package

Technical Evaluation

Architecture fit. This is a single Nova field — one class plus one compiled Vue component — that adds a boolean toggle to the resource index table. It has no service provider surface, no config file, no migrations, and no API of its own. Architecturally it is a leaf-node dependency: it either drops into a Nova resource's fields() array cleanly or it doesn't run at all. That simplicity is the whole value proposition and the whole risk. There is nothing to integrate with beyond Nova itself.

The decisive gate is the Nova major version. The package was built against Nova 3 (Vue 2 + Laravel Mix), with compiled assets frozen at 2021-05-31. On Nova 4/5 (Vue 3 + Vite) the shipped dist/js/field.js will not boot. This is a binary, cheap-to-settle question and it should be settled before any further evaluation spend: run composer show laravel/nova, and if it reports 4.x or 5.x, the honest answer is "reimplement natively or fork," not "adopt." Rebuilding the asset requires the laravel-nova build alias, which only exists inside a licensed Nova install — so "just rebuild it" cannot be validated in CI and is not a free fix.

The second gate is the write path. Grep the Vue component for the URL it posts to. If it goes through /nova-api/{resource}/{id} with PUT, then Nova's update controller, update policies, readonly, and canSee all still apply, and the security posture is acceptable. If it posts to a custom route, inline writes bypass policies — treat that as a disqualifier for anything beyond a throwaway spike. This determination takes ten minutes and changes the entire adoption decision.

Technical risk, ranked.

1. Silent failure. A mismatched compiled asset can render a switch that looks right, flips optimistically, and never persists — or persists and never reverts on error. This is the worst outcome because it corrupts operator trust in the admin surface without producing a visible error.
2. Abandonment. 3 stars, 0 dependents, no release since May 2021. Treat upstream as dead on arrival; there will be no security patches, no Nova-version compatibility work, no issue triage.
3. Context stripping. Model events still fire, so updated observers and spatie/laravel-activitylog work unchanged — but form-derived context (updated_by auto-fill, reason-for-change fields, approval workflows, observers that read $request->input()) is absent. Any observer assuming a form submission will null-reference.
4. Accessibility. A 2021 custom toggle is typically a styled <div> with a click handler, not a real <input type="checkbox"> with focus states. If operators use keyboards or you have accessibility obligations, this is a rebuild, not a retrofit.

Key questions the TPM should force to closure before a sprint is committed.

• What exact Nova version are we on, and is an upgrade planned within the next two quarters? (If yes, the answer is "don't adopt.")
• Which specific boolean, on which resource, do operators flip most often — and how many times per session, measured, not assumed?
• Does the write path go through Nova's standard update endpoint, and does a read-only user get a 403 with the DB unchanged?
• Do we need per-field audit history? If yes, audit must land before the toggle goes live — there is no backfill.
• Does this boolean gate publication, access, billing, or tenant state? If so, stop: inline toggling strips the approval and reason context a regulated flow requires.
• Who owns the fork after we vendor it, and what's the runbook step on every Nova major upgrade?

Integration Approach

Stack fit. Requires Laravel + Laravel Nova + PHP, nothing else. Fit is clean on Nova 3.x; on Nova 4/5 assume incompatibility until proven in a staging panel. There is no server-side footprint — no routes to register, no tables to migrate, no config to publish — so the integration is literally a composer require plus one line in fields().

Three viable paths, and the TPM owns the choice.

The recommended default is fork and vendor. The package is a few hundred lines end to end; owning it costs less than the ongoing diligence of trusting an unmaintained compiled bundle, and vendoring into packages/ or a private repo under your namespace removes the pre-compiled-asset trust question entirely (you build from source you've read).

Migration and sequencing. The safe rollout is deliberately narrow and time-boxed:

1. Version gate + code read (day 0.5). Confirm Nova version; grep the Vue component for the write URL; confirm the PSR-4 namespace from composer.json. Stop here if the gate fails.
2. Vendor and pin (day 0.5). Clone into packages/, pin the commit, register as a path repository. Never take a floating constraint against an abandoned upstream.
3. Land audit first (day 1). Wire the updated observer / activity log before operators touch the toggle. Retrofitting audit leaves an unbackfillable gap in the history.
4. Single flag, single resource (day 1). Use is_featured-class flags — not is_published, not anything gating access or billing. Keep the native Boolean field on the detail form via ->onlyOnDetail() so validation and reason fields survive on edit, and mark the inline field ->onlyOnIndex().
5. Verify the network, not the UI (day 1). Open DevTools, click, and read the request: URL/method, status code, whether the UI reverts on 500 or a blocked request, and assertDatabaseHas after a successful click. A toggle that renders but doesn't persist is the expected failure mode.
6. Feature-test the endpoint (day 1.5). A test around PUT /nova-api/{resource}/{id} plus a 403 assertion for a read-only user survives a JS rebuild; a component test does not.
7. One week of measured use. The activity log gives you the usage count for free. If operators don't use it, the loop wasn't worth optimizing — you've spent two days and learned that cheaply.

Compatibility sequencing against Nova upgrades. Every Nova major upgrade needs explicit runbook steps: rebuild the vendored assets against the new laravel-nova alias, smoke-test the toggle in staging, verify persistence in the DB. That precise step is where the original package stopped being maintained — make it a named line item, not a hope.

Operational Impact

Maintenance. Low in absolute terms, non-zero in practice. There is no runtime surface, no dependency tree, no migration drift. The recurring obligation is narrow but real: fork upkeep, an asset rebuild and smoke test on every Nova major upgrade, and no security patches arriving from upstream. Budget roughly 0.5–1 engineer-day per Nova major upgrade, and near-zero in steady state.

Support. Effectively none from upstream — abandoned as of May 2021 with a 3-star, 0-dependent footprint. Internal ownership is mandatory, not optional. The upside: because the package is small and there's no extension surface, the owner reads the whole thing in under an hour, which caps the support burden at "one engineer who has read ~200 lines."

Scaling. The field itself scales trivially — one AJAX PUT per click through Nova's standard update controller, which any admin backend already handles. The scaling concerns are organizational:

• Concurrency: two operators flipping the same flag will last-write-wins with no conflict signal. Acceptable for display flags; unacceptable for state-machine transitions.
• Bulk operations: Nova bulk actions are an unrelated code path. Do not let the toggle's presence substitute for a real bulk affordance — ten records means a Nova Action, not ten clicks.
• Audit volume: per-toggle activity-log rows in a high-frequency moderation queue can add up; size the activity table's retention accordingly.

Failure modes to instrument and alert on.

• Silent no-op — switch renders and animates but the DB is unchanged (Nova runtime mismatch, wrong attribute name, fillable/cast issue). Detection: DB-verified feature test in CI, plus periodic spot checks.
• Optimistic flip with no rollback — UI shows true, server returned 500. Detection: if forking, add explicit non-2xx revert + error surface.
• Authorization bypass — only possible if the write path is a custom route rather than Nova's update endpoint. Detection: settled at the code-read gate.
• 419 on long-lived admin tabs — inline writes are more session-expiry-sensitive than form saves because operators click rapidly and don't re-read the page. Detection: verify the field prompts a reload rather than desyncing.
• Observer null-reference — a saving/updated observer that reads $request->input('reason') blows up on an inline write. Detection: surfaces as a 500 on the toggle; catch it in staging.
• Policy leak via canSee alone — canSee hides the button; it does not authorize the write. Detection: the 403 feature test.

Ramp-up. Very fast — the field is one line in a resource's fields(). A developer unfamiliar with Nova fields is productive in under an hour; the harder ramp is organizational, not technical: getting audit logging live before enablement, getting the policy and 403 test in place, and getting product agreement that this is scoped to low-consequence display flags only. That conversation is where the real TPM effort sits, and it's the reason to run this as a bounded probe rather than a platform commitment.

Net TPM read. Evaluate it as a UX specification first and a library second. The package's genuine value is that it surfaces the hidden requirements behind "a simple toggle" — audit trails, per-role permissions, rollback semantics, bulk actions, accessibility — early enough to re-scope the estimate before a sprint is committed. Adopt only on Nova 3.x with the standard update endpoint and a low-consequence flag; otherwise vendor the pattern and build it natively in about a day.