Nova Button Laravel Package

Product Decisions This Supports

• Build vs. buy for admin-panel affordances. Every internal tool accumulates “run this one thing on this one record” needs — approve, resend invite, sync to ERP, open in Stripe, impersonate, mark reviewed, re-run provisioning. The default answer is a custom Nova Tool, a bespoke Vue component, or a one-off controller plus a Blade partial — each carrying a build pipeline, an internal component API, and ongoing front-end maintenance. This package reduces that to a declarative field config inside the resource class. Make it a standing decision: single-record action buttons are bought, not built. That keeps scarce admin/front-end capacity pointed at genuinely custom screens instead of the tenth variation of confirm-and-POST.

• Roadmap sequencing around backend readiness rather than front-end capacity. When a button is a config line, the gating dependency for an operator workflow flips from “when does a front-end dev have a sprint” to “does the endpoint exist and is it authorized?” That changes how you sequence ops-productivity initiatives (e.g., “cut manual support tickets 20%,” “reduce time-to-approve for onboarding”) — you can ship them opportunistically as backend work lands, instead of batching them into a UI-themed quarter.

• Cheap, reversible iteration on operator flows. Labels, icons, colors, target behavior, per-row visibility, and confirmation copy all live in PHP next to the fields. Product and Ops can run small experiments — tighten a confirmation prompt after a misfire, gate a button behind a status condition, hide a dangerous affordance from non-admins — via a PR, with no design cycle and no release train. That is iteration velocity usually reserved for consumer surfaces, now available on internal tooling for free.

• Making the buttons-vs-Actions boundary an explicit product decision. This package is for single-record, click-to-run affordances. Nova’s built-in Actions cover bulk selection, queued jobs, and multi-record operations; Nova Tools cover multi-step flows with forms and branching. Writing that boundary into the team’s conventions doc up front prevents the classic drift where a button gets bent into a workflow engine it was never designed to be — with the resulting authorization and idempotency debt landing on whoever is on call six months later.

• Risk budgeting for a narrow, low-exit-cost dependency. 37 stars, single maintainer, 0 listed dependents, MIT, last release February 2025. That is an acceptable signal for a surface this small, but it is a bet to size rather than ignore. Two mitigating facts: Nova is commercial and not distributed via Packagist, so dependent counts structurally under-report adoption for any Nova add-on — 0 here is far less alarming than it would be for a general-purpose Laravel package; and MIT licensing means forking is always available, capping the downside at “carry a small patch set” rather than “blocked on a vendor.” The real risk is internal abandonment, not upstream abandonment — name an owner.

• Where not to spend the decision. This is not a platform bet, a data-layer choice, or an architecture commitment. It is a view-layer convenience whose exit cost is measured in one file — provided you wrap it (see below). The PM decision is scoping and ownership, not strategy. Resist the urge to turn a two-hour adoption into a two-week evaluation.

When to Consider This Package

Adopt when:

• You already run Laravel Nova 4+ and the button need recurs across multiple resources. Value scales with repetition — a single button probably isn’t worth a dependency, five or ten across a growing admin panel almost certainly is.
• The action is lightweight and single-record: a link or deep link into another tool, a hit to an existing endpoint, or a single confirm-and-fire step. No wizard, no file upload, no multi-record selection.
• Your team would rather maintain a config line than a Vue component, and has no appetite for a custom front-end build pipeline living inside the admin panel.
• You can commit to two small disciplines on day one: an internal wrapper field class so vendor references exist in exactly one file, and a rule that every mutating button routes through a Nova Action (or a policy-guarded endpoint) rather than an ad-hoc admin route. Without those, you are borrowing convenience against future authorization debt.
• You have, or can name, one engineer as owner of the admin-panel button catalogue.

Look elsewhere when:

• Nova isn’t in the stack, or you’re not on 4+. “Nova 4+” is a floor, not a tested forward-compatibility promise; Nova’s internal Vue component API is not a public stability contract. Pin the package and Nova together and upgrade them in the same commit.
• The need is bulk or queued. Use Nova Actions — they already carry authorization, queuing, and progress semantics. Bending a button into batch work is exactly the drift that creates audit gaps.
• The need is multi-step: a form, a wizard, conditional branching, or anything that needs to collect input before acting. That is a Nova Tool, honestly and without compromise. A button that opens a modal with three fields is a Tool wearing a button costume.
• The need is high-stakes and irreversible with no independent server-side idempotency guard available. Confirmation dialogs and canSee are client-side UX hygiene, not security controls; if the backing endpoint can’t protect itself, ship the backend first.
• The action is long-running (30-second ERP sync, bulk export) and you can’t route it through a queue or surface progress. A synchronous button that times out trains operators to click three times, which is worse than no button.
• You’re on a single-resource, one-off need and expect no further instances. Write the four lines inline; don’t take the dependency for a data point of one.

Adoption gate (a two-hour spike, not a project): install, wrap the field class, ship one read-only button (“Open in Stripe,” “View invoice PDF”) to staging, and check three things — does it render, does it survive a Nova version bump, and is the prebuilt dist/ asset reviewed or reproducible in CI. dist/ is compiled JavaScript entering your highest-privilege authenticated UI; treat reviewing or rebuilding it as a supply-chain decision, not a convenience.

How to Pitch It (Stakeholders)

To executives — in one paragraph: We can add single-click action buttons to our internal admin panel — approve, resend, sync, deep-link into Stripe or the ERP — for roughly the cost of a config line per button instead of a front-end project per button. It’s MIT-licensed, it’s a small dependency we can fork or replace in a single file, and the real cost isn’t the package — it’s the authorization, audit logging, and idempotency behind each button, which we should budget separately and would have to build anyway. The decision I’m asking for is not “is this strategic” — it isn’t — it’s “do we standardize on bought buttons for single-record operator actions,” which frees admin front-end capacity for the screens that actually are custom.

To engineering — in one paragraph: It’s a Nova field that renders a button and wires it to a URL, a route, or an existing Nova Action, with confirm() for destructive copy and canSee() for per-row state and policy gating. The surface is tiny — read vendor/sietse85/nova-button/src/ before the README; the README documents a snapshot, not a contract. Two non-negotiables: (1) wrap it in App\Nova\Fields\ActionButton on day one so the vendor class appears in exactly one file and exit cost is a rewrite, not a grep; (2) anything that mutates state fires a Nova Action or a policy-guarded endpoint — never a new ad-hoc POST /admin/.../do-thing route. canSee is UX hygiene, not a security control; the endpoint enforces the policy independently. Keep mutating buttons onlyOnDetail() — index placement multiplies DOM weight, visual noise, and N+1 risk from canSee closures. Make non-idempotent endpoints idempotent server-side, because confirmation dialogs don’t stop double-clicks. Add a post-Nova-upgrade checklist item to click one button in staging and check the console — this class of breakage fails silently as a blank cell, never as a 500.

The one risk to state plainly: single maintainer, small user base, latest release February 2025. The mitigations are structural, not hopeful — MIT means we can fork, the wrapper class means the swap is one file, and the surface is small enough that a self-maintained patch set is realistic. Nova’s commercial distribution means Packagist dependent counts under-report adoption across the whole ecosystem, so the “0 dependents” number is less alarming here than it looks. What actually kills this is nobody owning it internally; assign an owner or it becomes orphaned infrastructure inside our own org within two quarters.