Dynamic Field Laravel Package

Product Decisions This Supports

• Build vs. buy for admin-side form logic. If your roadmap includes "fields that react to other fields" (show/hide, enable/disable, cascade options, swap input types based on a parent selection), this package is a candidate substitute for 1–3 days of custom Nova field development. The decision it informs is: spend engineering time writing a bespoke Vue/Nova field, or composer require this and spend that time on product.
• Feature scoping for internal tooling. Conditional field behavior is usually a supporting feature on an ops/back-office backlog — it unblocks CS, finance, or support workflows without touching the customer-facing product. This package lets you say "yes" to those requests with a low-ceremony implementation.
• Roadmap sequencing for admin UX debt. If your internal users are complaining about 40-field forms where 30 are irrelevant per record type, dynamic fields are a cheap UX win vs. a full admin redesign. This is a "do it this sprint" candidate, not a "next quarter" one.
• Use cases that justify it concretely: multi-tenant admin panels where fields vary by plan or role; config-driven record types where one Nova resource serves several schemas; regional/compliance variants where some fields only apply to certain jurisdictions; approval workflows where fields lock after submission.
• Framework selection pressure. It is a data point in the larger "Nova vs. Filament vs. hand-rolled Inertia admin" conversation — every plugin you adopt is a small vote for staying on Nova.

When to Consider This Package

Adopt (or trial) when:

• You are already running Laravel Nova and paying for the license — the marginal cost of this package is near zero, and the alternative is custom field code you'd own anyway.
• The dynamic behavior you need is generic (dependency/visibility/cascade), not deeply product-specific. If it's specific, you'll fork it, and forking a 300-line field is fine.
• The blast radius is internal: admin users, not customers. A bug here is an annoyance, not an outage or a data-integrity event.
• Someone on the team can read the Vue component and the Nova field API. Treat this as a starting point you own, not a dependency you consume.
• You pin the version, commit the vendor copy or fork it to your org, and add it to your Nova-version-upgrade checklist.

Look elsewhere when:

• You are not on Nova, or you're evaluating Nova now. Filament is free, actively maintained, and has a rich ecosystem — adopting a paid framework plus a single-maintainer plugin is a compounding bet. Make that comparison before, not after.
• The surface is customer-facing. Customer forms need maintained validation, accessibility, localization, and real support. Use Livewire/Inertia with a maintained form layer, or buy a form product.
• You need a support contract, SLAs, or guaranteed compatibility with the next two Nova majors. 18 stars and 0 dependents is the opposite of ecosystem validation — there is no downstream usage to shake out bugs before you hit them.
• The need is trivial. One if around a field's visibility belongs in your own field class; adding a third-party dependency for that is negative value.
• Due diligence flags fire: check last commit date, open issues, Nova 4/5 compatibility, PHP/Composer constraints, license, and whether the repo's README actually documents the API you need. Verify these before committing to a plan — the metadata here is thin enough that the honest answer is "evaluate in a spike."

PM framing: treat this as a time-boxed spike (half a day), not an architecture decision. If the spike passes, vendor it; if not, budget the custom field.

How to Pitch It (Stakeholders)

For executives (one paragraph): Our admin tooling runs on Laravel Nova, which we already pay for. Internal teams keep asking for smarter forms — fields that appear, hide, or change options based on what's already been entered. Building that ourselves is a few days of engineering per instance; there's an existing open-source Nova field that covers the common cases for free. The catch is it's a small, single-maintainer project with no downstream users, so we'd take a copy into our own repo rather than depend on it long-term. Recommendation: a one-day evaluation, then adopt-and-own or build our own. Low cost, low risk, real time savings on a recurring class of requests.

For engineering (the actual ask):

• Dependency is a Nova field (PHP class + Vue component). Expected scope: conditional visibility, dependent/disabled state, dynamic option sourcing. Confirm the README covers your exact case before designing around it.
• Risk posture: unmaintained-project assumption. We pin the version, fork to our org, and add it to the Nova upgrade checklist. No transitive dependency expansion without review.
• Effort: ~0.5 day spike on a real resource, ~1 day to fork and harden if we adopt. Compare against an estimated 2–3 days to write and test a custom field plus its Vue component.
• Exit criteria for the spike: works on our Nova version, no console errors, behavior is driven by our own field config (not hardcoded), and the component is small enough to reason about. If any fail, we build it ourselves — the fallback is cheap, which is exactly why the spike is worth running.
• Non-goal: customer-facing forms. This stays inside /nova.