Nova Detached Actions Laravel Package

Technical Evaluation

Architecture fit. The package is a thin presentation layer, not a subsystem. It overrides Nova's resource toolbar Blade partial to render buttons that fire ordinary Laravel\Nova\Actions\Action instances without a checkbox selection, and ships pre-compiled JS/CSS to wire the modal lifecycle. Nothing about our domain model, resource classes, or policy layer changes — a detached action is the same class we already write for row selection. That is the strongest architectural argument: zero new abstraction to learn, zero parallel permissions model, and existing ExportAction-style classes are reusable verbatim. The "architecture" we're really adopting is a Blade partial plus a registration convention.

Integration feasibility. High effort-to-value ratio, contingent on one disqualifying question: our Nova major. The package is frozen at the Nova 2/3 era (PHP 7.4/8.0, Laravel 6–8), last released 2020-10-11, archived upstream, with zero dependents. On Nova 4/5 the answer is fork-or-reimplement, not install. A second unknown is the asset pipeline — the compiled bundle is the silent failure surface (buttons render, clicks do nothing, no PHP exception). Both are 30-minute spikes, but they must happen before any estimate is committed.

Technical risk. Concentrated and knowable:

• Lifecycle: archived, no maintainer, no security review, no support contract. This is a vendored MIT utility we own, not a dependency we consume.
• Silent asset drift on any Nova upgrade — the highest-probability failure mode and the least visible.
• Empty-model invocation. Detached calls pass no models; an action written for row selection that assumes a non-empty collection will misbehave. This is the most common implementation bug and it is ours to prevent, not the package's.
• Authorization exposure. Bypassing the checkbox gate means a registration mistake puts a maintenance command in front of users who shouldn't have it. Inheriting authorizedToSee/canRun is a genuine strength, but it only holds if we test it.
• UX inheritance. The overflow "more" menu and registration-order-as-visual-order are fixed 2020 decisions we inherit as-is; nothing is configurable.

Key questions.

1. Which Nova major are we on today, and is a Nova 4/5 upgrade on the roadmap within ~18 months? (If yes to the second, this is a migration cost line, not a feature.)
2. Does the published asset bundle still initialize against our Nova build in a staging environment?
3. Who owns the fork — a named engineer and a named service?
4. Which actions get buttons, for which roles, with what confirmation? (Risk and value are per-action, not per-package.)
5. Is a hand-rolled toolbar partial or small custom Nova tool plausibly cheaper than forking this? The API surface is small enough that "build" is credible.
6. Where do run outcomes live? This package provides no history, retries, or scheduling.

Integration Approach

Stack fit. Native fit if and only if we're a licensed Nova shop on the matching major. It composes with things we already use — Nova actions, action fields, confirmation modals, policies — and adds nothing new to reason about at runtime. It is inert for Filament, Inertia/SPA admin surfaces, or custom builds.

Migration path. Treat this as an internalization, not an install:

1. Copy the source into an internal namespace, pin via a path or VCS composer repository, tag it, name an owner. MIT makes this free and this step is the whole recovery plan.
2. Publish and commit the assets (or verify the service provider auto-registers them) so the bundle is version-controlled with our code rather than floating.
3. Read the service provider and toolbar Blade partial once, end to end — that's the entire API surface and it settles which Blade view we're overriding and how the package's rendering interacts with Nova's own standalone semantics.
4. Fork the partial into our view namespace only when we need restyling; keep patches small and documented so the next Nova upgrade is a diff, not archaeology.

Compatibility. Gate everything on composer show laravel/nova matched against the package era. Validate on a staging instance with the real asset pipeline before writing domain code. Do not accept "it installed" as evidence — asset staleness is invisible until a click fails.

Sequencing.

• Spike first (½ day): Nova/PHP/Laravel compatibility + asset render + modal open. Fail here and the decision is reimplement.
• Lowest-risk action second: register an existing read-only ExportAction detached on an index screen. Prove button placement, ordering, modal lifecycle, and icon rendering. No writes yet.
• Security test third: assert a user lacking the policy ability can neither see the button nor execute the action via a direct request. This is the entire security story and it should land before the first write-capable action.
• Write actions fourth: imports, index rebuilds, cache flushes — each behind ShouldQueue or an explicit queue dispatch inside handle(), with results written somewhere durable.
• Cleanup last: keep row-specific actions on the checkbox path; register only genuinely resource-wide commands as detached. Do not dual-register unless handle() is correct for both zero and n models.

Operational Impact

Maintenance. Near-zero until Nova, PHP, or Laravel moves — then we are the maintainer, full stop. Budget this honestly: put a review on the calendar alongside every framework upgrade rather than discovering it at upgrade time. Because the upstream is archived with no dependents and no community to lean on for fixes, every future issue is first-party. That is acceptable for a toolbar partial and unacceptable if anyone starts treating it as infrastructure.

Support. None, and there will not be one. No CVE process, no upstream responsiveness, no compatibility guarantees. Mitigation is structural: vendored source, pinned tag, named owner, and an internal note in the repo explaining what the fork patches and why. Do not adopt if a support contract or security review is a procurement requirement.

Scaling. Two axes, both bounded:

• Button count per screen. Registration order is visual order (first entry nearest Create), and 1.1.1 adds an automatic "more" overflow menu. That handles growth from three buttons to maybe a dozen, but it is a decade-old breakpoint decision — test at our real admin viewport widths, because responsive behaviour is the thing most likely to look wrong on widescreen.
• Execution scale. Detached does not mean asynchronous. A 40-second export blocks the request and times out regardless of where the button lives. Anything heavy must implement ShouldQueue and persist results outside the package.

The package itself scales fine because it does almost nothing; our queue and logging carry the load.

Failure modes.

• Silent asset drift — buttons render, modals don't open, no error. Check published assets first, always.
• Empty-input mishandling — the action assumes models and either no-ops or does the wrong thing at scale. Guard at the top of handle() and decide explicitly whether empty means "all records" or "invalid invocation."
• Over-broad exposure — a registration or authorization mistake surfaces a maintenance command to the wrong role. The one test we write exists to catch this.
• Phantom operations — a stakeholder asks "did the import run and what did it do," and the answer doesn't exist. Say out loud now that this is a button, not a job runner; anything resembling an ops workflow needs queue, log table, and probably notification.
• Upgrade cliff — Nova 4/5 arrives and the toolbar silently stops working. Price this into the migration plan when the upgrade is scoped, not when it ships.

Ramp-up. Low, and that's the point. An engineer who has written one Nova action can ship a detached button in an afternoon — the registration snippet is the entire API and the examples are short. The non-obvious knowledge is concentrated in four lessons worth writing down once for the team: registration order is visual order, detached actions receive no models, asset staleness fails silently, and authorization must be proven with a test. Everything else is inherited Nova behaviour. Realistic ramp: half a day to a first read-only button, one to two days to a secure, queued, logged write action.