- What does tunezilla/dynamic-action-fields actually do?
- It lets you define an action's fields dynamically at runtime instead of hardcoding them in the Action::fields() method. Nova resolves Action::fields() when the action is serialized for its modal, and this package wraps that seam behind an opt-in trait or base class. The practical result is that inputs can vary by selected resource, acting user, tenant, or a prior selection without forking action classes or stacking conditionals in one method. It only affects the action layer of an admin panel.
- How do I install it in a Laravel Nova project?
- Install it with Composer using the package name tunezilla/dynamic-action-fields. It requires Laravel with Nova installed and PHP 8.x, and plugs into the existing service-provider flow with no new runtime services, queues, or storage. After installing, opt your action in via the provided trait or base class. Because Nova is closed-source and paid, confirm the declared compatibility range against your installed Nova version before rolling it out.
- Which Laravel Nova and PHP versions are supported?
- The package declares whatever its single maintainer has tested, and PHP 8.x is the expected baseline. Nova's action serialization and field APIs have shifted across 4.x into 5.x, so the exact supported minor matters. Check the composer.json constraints and any CI configuration rather than assuming, and run a quick spike against your installed Nova version specifically.
- Does this package require Laravel Nova, or does it work with plain Laravel actions?
- It is Nova-specific. The repository name and title reference Laravel Nova, even though some summary prose phrases it as generic application actions. Record it as a Nova dependency in your register and do not assume it generalizes to non-Nova action patterns. Because Nova is required, you inherit Nova's licensing and upgrade cadence as part of the dependency.
- Are the dynamic fields resolved once at modal open, or reactively as sibling fields change?
- That is unresolved until you test it. One-shot resolution at modal open happens against the request payload, while reactive resolution as sibling fields change requires a JavaScript/Vue layer and carries a materially different risk profile. The cascading-select use case that most justifies the dependency depends entirely on which is true. Verify this in a spike before it appears in any plan.
- Does validation run through the same dynamic resolution path as rendering?
- This needs to be verified, and it is a correctness blocker if it is not. If rules resolve through the same dynamic path as rendering, behavior stays coherent. If rules are re-derived separately, you can get required-but-hidden fields, or on data-mutating admin actions, values that pass unchecked. Gate this as a hard requirement rather than treating it as a cosmetic defect.
- Will it conflict with Nova's native dependsOn or withMeta?
- That is an open question and should be tested explicitly. The concern is double-serialization when both mechanisms write to the same field metadata. Run a spike that combines a dynamically resolved field with a native dependsOn or withMeta definition on the same action. If they coexist cleanly, you can use each where it fits best.
- Can defaults be seeded from the selected models on the action?
- This depends on whether the trait exposes the action's target models to your field-building code. If it does, you can prefill fields from the selected rows when the modal opens. If it does not, you are limited to values available in the request payload. Confirm this in the one-day spike, since it drives a lot of the usability payoff for bulk admin workflows.
- Is it safe to use in production given the low star count and single maintainer?
- It is a structural risk rather than something diligence fixes: around 18 stars, zero dependents, and effectively one maintainer, so you will be the first production user of your exact Nova minor with no downstream canary. The mitigating factor is blast radius—it touches nothing in resources, models, Nova bootstrapping, queues, or storage, so it stays off the critical path for APIs and background workloads. Treat the first action as a spike with a hard exit criterion rather than the first item in a rollout.
- What are the alternatives, and how hard is it to remove this package later?
- The alternatives are the status quo: separate forked action classes per variable-input workflow, or a pile of conditionals inside a single fields() method. Both work but do not scale as a repeatable, estimable unit of work. Because the package is a thin trait or base class, vendor-forking or inlining it into your own codebase is a realistic escape hatch if the maintainer stops keeping pace with Nova. MIT licensing makes that option straightforward.