Dynamic Action Modal Laravel Package

Technical Evaluation

Architecture fit. The package is a Laravel Nova extension that makes the fields inside an Action's modal reactive — i.e., the field set rendered when a user triggers a Nova Action can change in response to other field values (dependent selects, conditional inputs). That is a legitimate gap in older Nova releases, where dependsOn() reactivity existed for resource/form fields but action fields were largely static. Architecturally it therefore sits in the presentation layer of an admin panel: a Vue component that swaps or extends Nova's ActionModal, plus a PHP service provider to register/publish the assets. It does not touch domain logic, persistence, or queues.

Integration feasibility. Low-to-moderate effort if the host application is on the right stack — and it almost certainly is not. The declared constraint is php <= 7.3.0, which caps the host at Laravel 8 (Laravel 9+ requires PHP ^8.0). Nova 3.x is the corresponding admin panel generation. Any current Laravel application (10/11/12, PHP 8.1–8.4) will fail Composer's platform resolution; forcing it with --ignore-platform-reqs only defers the failure to runtime. Beyond PHP, Nova 4/5 moved to an Inertia + Vue 3 front end and reworked the action modal internals, so a 2021-era Vue 2 component overriding ActionModal is expected to break outright.

Technical risk. High, on several independent axes:

• Abandonment. Zero stars, zero dependents, single author, last release December 2021. This is a personal/experimental repository, not a maintained dependency. Bus factor is 1 and effectively already realized.
• Licensing. NOASSERTION means no machine-readable or clearly stated license. Shipping this inside a commercial product without written clarification from the author is a legal exposure we should not accept.
• Coupling to Nova internals. The package's value depends on overriding a core Nova UI component. That is the most brittle possible integration surface — any Nova patch release can silently break it, and Nova is a paid, closed-source product we cannot patch.
• Silent-failure shape. A broken reactive modal does not throw; it renders incorrectly or executes the action with stale/defaulted field values. That is a data-integrity failure mode disguised as a UI bug.
• Audit surface. Unvetted third-party Vue bundles get compiled into the admin panel — the highest-privilege surface in the app.

Key questions. What Nova version was this built and tested against? Is the JS a fork of a Nova core component (raising redistribution questions under Nova's license)? What is the author's intended license, and will they grant one in writing? Does Nova's current release already provide dependsOn() for action fields — making this redundant? What is the actual business requirement driving dynamic action fields, and can it be met with a maintained alternative or a small in-house component?

Integration Approach

Stack fit. Assume non-fit until proven otherwise. The realistic target is a legacy Laravel 7/8 + Nova 3 application, or a modernization effort where this functionality is a known gap. On a current stack, treat the repository as a reference implementation, not a dependency.

Migration path. In preference order:

1. Reimplement natively. Check whether the installed Nova version already supports reactive action fields via dependsOn(); if so, the package is obsolete. Where it isn't, a single custom Action class plus a small Vue component is a few hundred lines — cheaper to own than to adopt.
2. Fork and vendor. If the existing implementation is genuinely useful, fork it into our own namespace, pin it to an exact Nova/PHP matrix, and treat it as first-party code with an owner. Do not depend on the upstream repo.
3. Adopt as-is. Only acceptable for a throwaway internal tool on a locked Laravel 8 stack, with no customer data and no upgrade path requirement.

Compatibility. Hard prerequisites to verify before any code is written: PHP version floor, Laravel version, exact Nova major/minor, Node/npm build toolchain for the published assets, and whether the compiled bundle targets Vue 2. Add a CI matrix job that installs the pinned Nova version and runs a smoke test against the action modal.

Sequencing. (1) Requirements spike — confirm which fields must be dynamic and why; (2) capability check against native Nova; (3) license clarification request to the author, in parallel; (4) go/no-go; (5) if go, fork + vendor + pin + add tests; (6) pilot on one low-risk action; (7) expand or replace. Budget the spike first — there is a real chance step (2) closes the ticket.

Operational Impact

Maintenance. Ownership transfers entirely to us on adoption. There is no upstream to merge from, no issue triage, no security patching. Every Nova upgrade becomes a manual regression test of this component. Realistically this is 2–5 days of engineering per Nova major upgrade, indefinitely, for a UI convenience feature.

Support. No vendor, no SLA, no community. Internal support means whoever wrote the fork is the support channel — a single-point-of-failure we should avoid replicating in the org chart.

Scaling. Runtime cost is negligible: it is client-side reactivity on an admin action modal, invoked by a handful of operators at human frequency. No throughput, memory, or concurrency concerns. The scaling problem is organizational (maintainer capacity), not infrastructural.

Failure modes.

• Nova minor upgrade → Vue component fails to mount → modal renders blank or falls back to static fields.
• Reactive state desync → action executes against default values → incorrect writes with no error surfaced. Highest-severity risk; mitigate with server-side validation in the Action's handle() that never trusts modal state.
• Asset publish mismatch after deploy → stale compiled JS served from public/vendor/.
• PHP platform constraint silently bypassed → fatal errors on an unrelated deploy.
• Unlicensed code discovered in an audit → forced removal under time pressure.

Ramp-up. The codebase is small and readable; a mid-level Laravel engineer with Vue 2 experience can be productive in under a day. The expensive knowledge is not the package — it is Nova's internal component contract, which is undocumented and version-specific. That knowledge evaporates on every Nova upgrade.

Recommendation. Do not take a production dependency on this package. Zero stars, zero dependents, no license, a two-year-old release, and a PHP ceiling that excludes every supported Laravel version collectively outweigh any convenience. Escalate to a short discovery spike to determine whether native Nova covers the requirement; if not, budget a small in-house implementation owned by the team.