Nova Button Laravel Package

Product Decisions This Supports

• Surface an existing operation instead of building an internal tool. The recurring decision behind this package is: do we stand up a bespoke admin screen to expose this action, or do we make it a button on the Nova resource we already have? dnwjn/nova-button answers it in a day rather than a sprint — a labeled Approve vendor, Resend invite, Sync to CRM, or Mark reviewed control on an index or detail view that fires an existing Nova Action or a policy-protected route. It is an acceleration decision, not a capability decision: native Nova Actions can already do the work.

• Reframe build-vs-buy as "depend vs. copy." This is a thin custom field wrapping Nova's action plumbing, not a platform. The honest roadmap framing is a short source review followed by one of three calls: adopt as a dependency, vendor the component into app/Nova/, or skip it and use native Actions. Budgeting it as a "buy" overstates the value; budgeting it as a "one-day internal build with a head start" is accurate.

• Sequence the Nova major upgrade as a two-dependency change. Release 5.0.0 adds Nova v5 support and drops v4 in the same breath — that is the package's entire versioning story. "Upgrade Nova" therefore becomes Nova major + package major, in one PR, on one rollback point. If a Nova upgrade is already penciled into the roadmap, this package's upgrade cost belongs inside that line item, not as its own.

• Stress-test the ecosystem assumption. Eleven stars, zero dependents, one maintainer porting on their own schedule after Nova ships. The 5.0.0 release is a mild positive — it is not abandoned — but if any roadmap assumes a rich third-party Nova plugin marketplace to lean on, that assumption deserves scrutiny. With Nova, "roll your own custom field" is the norm, and that labor should be budgeted as recurring cost.

• A scoping forcing function. The button is a click target and a label. Validation, permission matrices, audit trails, and multi-step confirmations belong in the Action or controller. If a proposed feature needs those inside the button, the requirement is mis-scoped and should be re-specced as application logic.

• Toolbar ergonomics as a real UX win. Grouping Approve / Reject / Hold into a visible row makes the decision set legible at a glance, versus hunting through Nova's action dropdown. That is the kind of small admin-efficiency gain that is cheap to ship and easy to justify.

When to Consider This Package

Consider it only when all of the following hold:

• You are already on Laravel Nova and paying for it. The package is worthless outside Nova, and 5.x is Nova v5-only by design.
• You need buttons in a shape Nova's native Actions UI does not cleanly provide — visible, labeled controls on index/detail views or inside forms. Validate this first; Actions with showOnIndex/showOnDetail cover a large share of real demand and are first-party and supported.
• The admin is internal-only, with no customer-facing SLA riding on the button rendering.
• A PHP developer owns the admin and can read, fork, and patch the field when the next Nova major breaks it.
• You can pin the package major and the Nova major in lockstep — no floating constraints — and accept being maintainer of last resort between the package's own upgrade releases.
• The action is non-destructive, or its authorization path has been verified from source (does the click go through Nova's action endpoint, middleware, and policies?) before it touches money or records.

Look elsewhere, or build it in-house, when:

• You are not on Nova. Use Filament or native Blade/Livewire. Do not adopt a paid admin panel just to get a button.
• You are on Nova v4 or earlier. 5.0.0 dropped v4 outright; you would be pinned to a frozen 4.x line — a worse position than vendoring. Read 5.0.0 as end-of-line for v4, not as an available upgrade.
• You need more than a thin button — complex validation, permission matrices, audit trails, async progress feedback, multi-step confirmations. That is application logic and belongs in your codebase where it is tested.
• Your Nova version is a major behind, ahead, or unpinned. There is no compatibility shim and no deprecation runway.
• You have a policy against low-adoption dependencies. Zero dependents is a real smell, not a formality.
• The action is destructive or financially material — at minimum until the dispatch path's authorization is confirmed from source.

How to Pitch It (Stakeholders)

Executives: This is a small, MIT-licensed UI helper for our internal admin panel. It saves roughly a day of developer time per workflow by letting us drop a visible, labeled button — approve, resend, sync — onto an existing Nova screen instead of building a separate internal tool or burying the operation in a dropdown. Cost is effectively zero and there is no vendor lock-in. Two things to know: it is a one-maintainer package with essentially no adoption, so we treat it as code we may have to own; and it upgrades in lockstep with Nova, meaning our next Nova major becomes a two-part change with a single rollback point. Recommendation: adopt it pinned and time-boxed for internal, non-destructive actions only.

Engineering: It is a Nova field, so it drops into fields() like anything else. The highest-leverage pattern is to keep business logic in Nova Actions — where policies, authorization, and queued execution already live — and use the button purely as a trigger surface. That gets us labeled buttons on index/detail views without forking Nova's action plumbing. Two non-negotiables before we ship anything real: (1) pin package major to Nova major in composer.json — ^5.0 for Nova 5 — and record that pairing in the repo, because these can no longer be upgraded independently; (2) read the Button class and confirm the click path goes through Nova's action endpoint, middleware, and policies rather than inventing its own route. If it does not, we add the policy checks ourselves before it touches a record. Start with one non-destructive detail-view button wired to an action we already trust ("Resend invite") as a smoke test — it validates provider registration, asset loading, and authorization in one shot. Vendor the component into app/Nova/ if we need more than one override, or if we are still on Nova 4.