Nova Action Button Selectors Laravel Package

Technical Evaluation

What it is: lexicon/nova-action-button-selectors is a Laravel Nova asset (a JS/Vue front-end component plus a thin PHP registration layer), not a service-side library. It exists to solve one narrow UI gap: Nova's native action buttons execute immediately, and this package lets an action button present a selector (dropdown) so the operator picks an option before the action fires. It has 17 stars, 0 dependents, and is archived upstream.

Architecture fit

• Fits only inside an existing Laravel Nova installation. Nova is a commercial, closed-source package with a paid license and a fast major-version cadence (Nova 4, 5); this asset's compatibility is effectively frozen at whatever Nova version existed when it was archived.
• Zero coupling to application domain code — it is a presentation-layer extension. That is good for blast radius, and bad for leverage: it delivers no backend capability, so its value is entirely "saved custom Vue work."
• Native alternative exists: Nova actions already support Action::fields() / ActionFields to collect input (including Select) in a confirmation modal before execution. Any use case this package serves is very likely expressible with first-party Nova APIs, without custom asset compilation.

Integration feasibility

• Mechanically straightforward: Composer install, register the asset in the Nova service provider / nova.mix.js, npm install && npm run dev|prod to compile, then expose it via a custom action or a Nova::script/Nova::style call. Realistically a 1–3 day spike for a mid-level Laravel engineer.
• The archived status means integration is a vendoring exercise, not a dependency exercise: fork the repo, pin it to your Nova/PHP/Laravel matrix, own the build, and treat the resulting component as internal code.

Technical risk

• High version-drift risk. Nova asset APIs (registering tools, Nova.booting, mix helpers, Vue 2 → Vue 3 transition in Nova 4/5) changed materially after this package's last commit. Expect the component to need porting, not just installing.
• No maintenance and no security response path. Archived + 0 dependents means no upstream triage for CVEs in the transitive npm build chain (Vue, webpack, postcss era tooling). Every future npm audit finding becomes your team's ticket.
• No test coverage signal. Nova assets of this vintage typically ship no automated tests; regressions surface only in manual QA of the admin UI.
• Low, contained impact if it fails. Admin-panel-only, no data-path or auth surface of its own (it inherits Nova's authorization), so a breakage degrades an operator workflow rather than corrupting data or exposing endpoints.
• Opportunity cost is the real risk. Team time spent owning a forked Vue asset is time not spent on first-party Nova APIs that ship supported.

Key questions

1. Which exact Nova major/minor version are we on now, and are we planning a Nova upgrade inside the next 12 months? (If yes, do not adopt.)
2. Does Action::fields() with a Select field cover the required UX — i.e., is the button-with-selector a genuine product requirement, or an aesthetic preference?
3. Is the required behaviour single-row, bulk, or both? Bulk selection semantics are where custom action components most often break.
4. Who owns the fork — is there a named engineer and an allocated maintenance budget, or is this a "someone installed it in 2021" orphan?
5. Do we have a compiled-asset pipeline (Node version, build step in CI/CD) that can reproducibly build a Nova asset, or is UI compilation ad hoc?
6. Are there other Nova assets already in the codebase, and does this add a second unsupported asset to the same upgrade surface?

Verdict signal: an archived, zero-dependent UI asset with a first-party equivalent is a replace, don't adopt candidate. Value it as reference source code and a UX pattern, not as a dependency.

Integration Approach

Stack fit

• Requirement envelope: Laravel + Nova + Node build toolchain for asset compilation. This package is only relevant if Nova is already licensed and in production — it adds no value outside that boundary and cannot be reused in a plain Laravel/Inertia/Livewire admin.
• Because it is front-end only, it composes safely with existing policies, authorization gates, and action queues: the selector decides parameters, Nova's action pipeline still enforces permissions. Confirm the action resolves parameters server-side and does not trust client-submitted values.

Recommended path (in preference order)

1. Build native (default). Implement the interaction as a standard Nova Action with an ActionFields-based modal containing a Select (options sourced from a PHP enum/config). Cost: ~1–2 days. Benefit: zero new dependency, survives Nova upgrades, no asset fork.
2. Adopt the pattern, not the package. Read the repo's Vue component as a worked example of Nova action-button customisation, then implement a minimal in-house component against the current Nova asset API. Cost: ~3–5 days. Benefit: you own it deliberately, with tests and a build step you control.
3. Fork and vendor (only if 1 and 2 fail). Copy source into resources/js/nova/, remove the Composer dependency, pin Nova, add the build to CI. Explicitly schedule the retirement ticket at fork time.

Migration path if already installed

• Inventory: confirm the current Composer constraint, the committed compiled assets in public/vendor, and every action that references the component.
• Freeze: convert to a path/VCS repository so upstream archival cannot silently break composer install on a clean machine.
• Port-forward: rebuild against the current Nova version in a branch, diff rendered behaviour against staging, then replace call sites one action at a time.

Compatibility

• Verify against the actual matrix: PHP version, Laravel version, Nova major, Node version. Nova's Vue 3 migration is the highest-probability break point.
• Check that the package's service provider uses discovery or is manually registered consistently with your other Nova assets; mixed registration styles are a common source of "works locally, blank panel in CI."

Sequencing

1. Spike (1 day): confirm whether native ActionFields reproduces the UX in staging. This is the cheapest possible decision point and should gate everything else.
2. Decide: native implementation, pattern reimplementation, or fork.
3. Pilot: one low-traffic action, feature-flagged if possible, with the old path retained behind a toggle.
4. Roll out action-by-action; do not convert all call sites in one release.
5. Retire the Composer dependency and delete the fork's dead code on a scheduled date.

Do not introduce this as a net-new Composer dependency in 2024+. Archived + 0 dependents + a first-party equivalent is a decisive combination.

Operational Impact

Maintenance

• Upstream maintenance is zero by definition. Total maintenance burden transfers to your team: Nova upgrades, Node/webpack drift, and dependency CVE triage in the compiled JS.
• Realistic steady-state cost if forked: a few hours per Nova major upgrade, plus audit-response time. Small in absolute terms, but it competes for the same senior front-end capacity as first-party work, and it is invisible on a roadmap.
• Bus factor: no upstream maintainer, no issue triage, no security advisories. Documentation is whatever the README says; tribal knowledge will be the actual spec.

Support

• No vendor, no SLA, no community. 17 stars and 0 dependents means Stack Overflow and GitHub issues are effectively dead channels.
• Internal support model must be "own it or replace it" — there is no escalation path. Name an owner in the PR that introduces it, or it becomes orphaned code that blocks a future Nova upgrade.

Scaling

• Horizontal scale is a non-issue: it renders in the browser and adds no server load, no queue, no database. It scales exactly as Nova scales.
• The scaling concern is organisational: every additional unsupported Nova asset multiplies the surface area a Nova major upgrade must validate. One is tolerable; five is a migration project.
• Options lists sourced from PHP are fine at small cardinality; if the selector needs hundreds of options, prefer server-side search or a Nova Select with searchable relationships rather than a client-side list.

Failure modes (ranked by likelihood and impact)

1. Blank/broken action button after a Nova upgrade — high likelihood, medium impact (operator blocked, no data loss). Detect via staging smoke test on the admin panel.
2. Silent parameter mismatch — the selector submits an option the server action does not expect; action no-ops or applies the default. Highest impact because it can produce wrong-but-successful-looking operations. Mitigate with server-side validation and explicit enum casting.
3. Build failure on clean install — committed compiled assets diverge from source, or the Node toolchain is unavailable in CI. Mitigate by building assets in the pipeline, not on a laptop.
4. Bulk-action semantics undefined — selector applies per-row vs once-per-batch ambiguity. Test explicitly if bulk actions are enabled.
5. Stale JS dependency CVE — medium likelihood over a multi-year horizon, low exploitability in an authenticated admin context, but still an audit finding.

Ramp-up

• Low: a Laravel engineer familiar with Nova can read the whole package in under an hour; the Vue component is small and self-contained.
• The real ramp-up is not the code, it is the Nova asset build model (mix config, asset registration, Vue version, public/vendor publishing) — a one-time cost most teams have already paid if they run any custom Nova tooling.
• Onboarding risk is concentrated in "why does this exist and who owns it?" — mitigate with a short ADR in the repo stating the requirement, the reason native ActionFields was rejected (if it was), and the retirement trigger.

Bottom line for planning: treat this as a reference implementation, not a dependency. Budget one day to prove the native Nova action-modal covers the requirement; if it does, close the evaluation. If it does not, budget three to five days for an owned in-house component and book zero days of ongoing external support — because there is none.