Nova Action Buttons Laravel Package

Technical Evaluation

Architecture fit. pavloniym/nova-action-buttons is a Nova 5 field type, not a framework or parallel admin layer. It renders existing Laravel\Nova\Actions\Action classes as buttons on index and detail views, so it inherits the authorization model already in the app (canSee/canRun/policies), confirmText() dialogs, onlyOnIndex/onlyOnDetail scoping, and the normal action lifecycle. No new persistence, no queue or worker, no external service, no second permission system to reconcile. For a team standardized on Laravel + Nova as internal admin substrate, this is a UI-surface addition rather than a platform commitment. The one architectural claim it makes is "configuration over Vue" — replacing bespoke Nova custom tools/cards with declarative button definitions. That trade is favourable for standard row-level workflows (approve, refund, retry, resend, escalate) and unfavourable the moment a workflow needs multi-step forms, wizards, or bespoke layout.

Integration feasibility. High, conditional on Nova 5. Composer install with package auto-discovery; no infrastructure prerequisites beyond an existing Nova 5 install. The binding constraint is the Nova major version: v2.x targets Nova 5, and mixing it with Nova 4 fails at render time (class-not-found / signature errors), not at install time — an expensive debugging mode if the version gate isn't verified first. Critically, v2.0.1 contains no code changes; it is a re-tag of v2.0.0 cut from cleaned-up main history. v2.0.0 is the actual upgrade event and the only source of Nova 5 breaking-change detail (PHP/Nova floors, renamed button APIs). Feasibility must be assessed against v2.0.0's notes, which are not reproduced in the 2.0.1 release document — the single largest information gap before committing engineering time.

Technical risk, ranked, because a TPM needs to know what actually kills the initiative:

1. Maintainer concentration (high impact, moderate likelihood). Single maintainer, MIT, ~15 stars, 0 dependents. Zero dependents means essentially no external production validation — we would be an early adopter, not a follower. Acceptable for internal tooling; not acceptable as a load-bearing dependency for revenue-critical back-office flows without a fork-or-vendor contingency.
2. Upstream coupling to commercial Nova (medium/medium). Nova is a paid, closed-source dependency on its own cadence. A field-level package cannot be more stable than Nova's API surface; a Nova 5.x point release is the most likely future break.
3. Unfixed defects (medium/medium). v2.0.1 ships no fixes; whatever v2.0.0 got wrong remains wrong. Reading the patch bump as a bugfix signal is the most likely process error here.
4. Per-row authorization cost (low/medium). Each button is an action Nova authorizes per row: six buttons on a 50-row index is roughly 300 canSee policy evaluations per page load. Fine for normal policies; a problem if canSee performs DB or API calls.
5. Silent UI regressions (low likelihood, high visibility). Published view overrides, long labels wrapping and displacing table layout, and double-submit on a larger click target all look cosmetic but surface as operator errors.

Key questions, required before greenlight, in priority order:

• What exactly changed in v2.0.0 — minimum Nova/PHP/Laravel versions, renamed or removed APIs, dropped v1 methods? What is the documented v1 → v2 migration?
• Are there automated tests, and do they run against multiple Nova 5 patch releases?
• Does the package honour onlyOnIndex/onlyOnDetail, lenses, relationship indexes, and per-row canSee, or does it bypass Nova visibility resolution anywhere?
• What is the maintainer's observed release cadence and issue-triage responsiveness over the last 12 months?
• Does it ship publishable views/config, and what is the upgrade story for published overrides (diff against vendor/ after each upgrade)?
• Are the target actions' handle() methods idempotent — i.e. does the application, not the package, own double-submit safety?

Integration Approach

Stack fit. Laravel Nova 5, which practically implies PHP 8.1+ and Laravel 10/11. Confirm the package's own composer.json constraints resolve against the exact laravel/nova version pinned in composer.lock before any planning estimate is produced. Not viable for Nova 3/4 fleets without pinning an earlier major — and running mixed package majors across a multi-app portfolio is itself upgrade friction that should be priced in, not waved away.

Migration path. Treat v2.0.0 as the breaking release and v2.0.1 as a no-op. If on v1.x, plan migration only after the Nova 5 upgrade lands; effort is a function of v2.0.0's changes (renamed classes, changed signatures) plus whatever Nova 5 itself forced. If already on 2.0.0, there is literally nothing to do — pin ^2.0 and move on. The TPM action is to correct any roadmap line saying "adopt 2.0.1 features": there are none, and scheduling against them wastes a sprint.

Compatibility. Two matrices must be checked, not one: package-against-Nova and Nova-against-Laravel/PHP. The package is a passenger on Nova's constraints. Validate against the exact Nova patch version running in production, not "Nova 5" generically.

Sequencing.

1. Gate: read v2.0.0 release notes; confirm Nova/PHP floors and API changes; confirm maintainer responsiveness from issue history.
2. Contingency: name an engineer who can fork and patch, and record that as a risk owner. Cheapest insurance available on a single-maintainer dependency.
3. Pilot: one internal, non-revenue-critical resource with a well-understood action lifecycle (content moderation approve/reject, or an ops "retry sync"). Replace the dropdown with a row of buttons on index only.
4. Verify in staging: authorization parity (canSee/canRun/policy), confirmation modals, onlyOnIndex/onlyOnDetail scoping, lens and relationship-index contexts, index render time before/after, narrow-viewport layout.
5. Measure: time-to-action for the target workflow, support tickets absorbed by the button, admin error rate, P95 index render time. A two-week pilot with those four numbers justifies or kills expansion.
6. Expand to the highest-ROI candidates — order management (refund/fulfill), support consoles (escalate/close), finance ops (re-run sync, resend invoice) — one resource at a time, fork contingency still open.
7. Defer anything needing multi-step forms, wizards, customer-facing surfaces, or bespoke layouts. Those remain build decisions.

Build vs. buy framing. "Buy" here is adoption of an MIT package; "build" is an in-house Nova custom tool or card in Vue. The package wins decisively on cost and time-to-ship for standard button-triggered actions with confirmation modals. Build in-house only when the workflow exceeds what a button plus modal can express, or when the dependency's maintainer risk has become unacceptable for that specific surface — in which case the fork option under MIT is cheaper than a rewrite. Also budget for the convention work, not just the dependency: agreeing which actions belong on the row versus in the toolbar is a product decision that outlives the package choice.

Operational Impact

Maintenance. Small surface area — a couple of files, config-driven, no component library to keep in step. Ongoing cost is roughly "re-verify after every Nova upgrade," plus a diff of any published Blade overrides against vendor/. Budget a half-day per Nova point release for re-verification, and never upgrade this package independently of Nova. MIT license keeps the fork option open, which is the real maintenance backstop.

Support. Internal-facing only — keep it out of anything customer-visible. Two interaction paradigms (dropdown versus button) carry real cognitive cost for admins, so publish a short convention: which actions get row buttons, and why. That document is what prevents "why is refund a button but cancel a dropdown" tickets. Day-to-day support burden is low; the escalation path for breakage is the named fork owner, not the maintainer's issue tracker.

Scaling. Two axes. First, rows × buttons: authorization cost grows linearly with both, so a 50-row index with six buttons is ~300 policy evaluations; keep canSee cheap (no DB or API calls) or move expensive checks into policy caching. Second, portfolio: every additional Nova app adds a version-skew surface. Standardize the package major per Nova major and document it centrally.

Failure modes, with the operator-visible symptom:

• Nova point-release break → 500 on index/detail render, not at deploy. Highest-frequency failure.
• Non-idempotent handle() → duplicate refunds/emails from a visible, easily double-clicked target. Application-owned, not package-owned — make idempotency a review checklist item.
• Authorization drift → button visible to a user who should not see it, usually because visibility was expressed in a view conditional instead of canSee. Keep authorization on the action class.
• Published view drift → cosmetic breakage after upgrade that passes tests and fails in front of operators.
• Abandonment → no upstream fixes; fork becomes permanent. Mitigated by the contingency and by scoping adoption to non-revenue-critical surfaces.
• Process failure → treating v2.0.1 as a feature or fix release. Correct this in planning artifacts explicitly.

Ramp-up. Days for one resource with a Laravel-fluent engineer; no Vue work required, which is the whole point. The learning curve is Nova internals (fields, actions, authorization resolution), not this package. Plan a two-week pilot with the four metrics above and a named owner; that is sufficient evidence to justify or kill broader rollout.