Nova Conditional Field Laravel Package

Technical Evaluation

Architecture fit This is a Laravel Nova custom field package, so it only has architectural relevance if Nova is already (or imminently) the admin surface for the application. It solves a narrow, well-understood problem: showing or hiding form fields based on the value of another field. In a Nova resource, that means wrapping a set of fields in a conditional container and declaring a dependency on a controlling field. The surface area is small and predictable — no database migrations, no service provider hooks into the request lifecycle, no new persistence layer. That is architecturally cheap, which is the main point in its favor.

The critical caveat: Laravel Nova 4+ shipped a native dependsOn() API for exactly this behavior, including conditional display and clearing of dependent fields. For any team on a current Nova release, this package is likely redundant. The evaluation should therefore begin with a build-vs-buy check against the platform primitive rather than against custom code. If the team is on Nova 3 or has a specific behavior Nova's native implementation does not cover, the package has a defensible niche.

Integration feasibility Low effort. Standard Composer install, field registration in the Nova resource, and a nova:publish / asset build step if the package ships compiled JS separately. A competent Nova developer can prototype a single resource in under a day. There are no external services, credentials, or infrastructure dependencies.

The feasibility question is not "can we integrate it" but "is it worth integrating" given the adoption profile.

Technical risk The risk profile is dominated by supply chain and longevity, not engineering complexity:

• Adoption signal is very weak. 16 stars and 0 dependents on Packagist means essentially no production validation outside the author's own use. There is no ecosystem evidence that edge cases (multi-step forms, dependent fields inside nested/repeatable layouts, file and relationship fields) have been exercised.
• Bus factor of one. A single maintainer with no downstream consumers is unlikely to prioritize a Nova 5 upgrade, a Vue 3 migration, or a security patch. Plan for the package becoming unmaintained at an arbitrary point.
• Framework coupling. Nova custom fields depend on Nova's internal field lifecycle and its Vue component contract. Nova major versions have historically broken custom fields, and Nova is a paid, closed-source product, so you cannot patch the host side yourself.
• Redundancy risk. If native dependsOn() covers the requirement, adopting this package adds a dependency that must later be removed.
• Security misread. Conditional visibility is a UI affordance, not an authorization control. Hidden fields can still be submitted, and validation still runs. Any workflow that treats "field is hidden" as "field is protected" is a design defect this package will not surface for you.

Key questions

1. Which Nova major version are we on, and does native dependsOn() already satisfy the requirement? What specifically does this package do that the native API does not?
2. Is the package's latest release compatible with our Nova, Laravel, PHP, and Node/Vue versions? Has it been updated since the last Nova major release?
3. Does the package clear dependent field values when the controller changes, or only hide them client-side? This determines whether stale data reaches the database.
4. Who owns the fork if the upstream goes dormant, and what is our remediation SLA?
5. Does the conditional logic need to hold for validation rules server-side, or is client-side hiding sufficient for the use case?
6. Are we willing to accept a non-permissive or unspecified license posture given zero downstream consumers?

Integration Approach

Stack fit Fits cleanly into a Laravel + Nova stack with no additional runtime. Assess fit on four axes: Nova major version, Laravel major version, PHP version, and the front-end build (Vue 2 for Nova 3, Vue 3 for Nova 4+). The package must match on all four. Any mismatch is a hard blocker, not a configuration problem, because Nova custom fields are compiled against the host's component contract.

Migration path Two directions matter and both are cheap:

• Adopting: install, wrap fields in the target resource, verify dependent-value clearing behavior, then expand resource by resource. Because the package is a field wrapper, adoption is incremental and per-resource rather than all-or-nothing.
• Exiting: if the package becomes unmaintained or native dependsOn() catches up, removal means unwrapping the field groups and re-declaring dependencies with the native API. That is mechanical work proportional to the number of resources touched, not a data migration. Keep the wrapper usage centralized (a shared helper or base resource) so the exit is a small diff rather than a sweep.

Compatibility Treat Nova upgrades as gated releases. Before any Nova bump, run the conditional-field resources through the upgrade test pass explicitly; custom fields are the most common silent breakage in Nova upgrades. Pin the Composer constraint tightly (patch-level where possible) and avoid floating constraints, since there is no downstream pressure to keep the package current.

Sequencing

1. Spike (1–2 days): confirm native dependsOn() gap, verify version compatibility, build a throwaway resource exercising the tricky field types.
2. Decision gate: adopt package, use native API, or write a thin in-house field. Document the rationale.
3. Pilot (1 resource): instrument for the failure modes below; confirm hidden-field values are not persisted unexpectedly and validation behaves.
4. Rollout: expand to remaining resources, keeping usage behind a shared abstraction.
5. Steady state: add the package to the dependency watch list and to the Nova upgrade checklist.

Operational Impact

Maintenance The realistic maintenance burden is small in code volume but non-zero in attention: the package must be tracked for compatibility with every Nova, Laravel, and PHP upgrade. Assign explicit ownership. Because there are zero dependents, expect to be the de facto maintainer of any fix you need — budget for the possibility of forking and vendoring, and confirm the license permits it before adopting.

Support No SLA, no vendor. Support is GitHub issues with an unknown response time from a single maintainer. That is acceptable for a non-critical admin convenience feature and unacceptable anywhere the conditional logic gates a regulated workflow (approvals, billing, access provisioning). Scope the feature's blast radius accordingly and keep fallback UX in place — e.g., server-side validation that holds regardless of what the client shows.

Scaling Negligible runtime and infrastructure cost. The logic is client-side rendering in the admin panel; it does not affect API throughput, queue behavior, or database load. The scaling concern is cognitive and organizational rather than technical: as the number of Nova resources grows, ad hoc per-resource conditional logic becomes inconsistent and hard to audit. Standardize on one mechanism (native or package) across the admin panel early.

Failure modes

• Silent breakage after a Nova upgrade: field renders but conditions no longer apply, or the component fails to mount and the field disappears from the form. Mitigation: post-upgrade smoke test on every resource using the package.
• Stale or unexpected data: hidden fields retain values that get persisted, or visible fields get cleared unintentionally. Mitigation: verify clearing semantics in the spike; enforce server-side validation independent of visibility.
• Asset/build drift: published JS out of sync with the installed PHP version. Mitigation: pin versions, include the publish step in deploy automation.
• Unmaintained upstream: no fix available for a blocking incompatibility. Mitigation: pre-agreed fork-and-vendor plan; centralized usage to keep the diff small.
• Security misconception: stakeholders assuming hidden means protected. Mitigation: state explicitly in the design doc that visibility is not authorization.

Ramp-up Very low. Any developer with Nova experience understands the field model in under an hour, and the package introduces no new concepts. The real ramp-up cost is onboarding the team to the decision: which conditional mechanism is canonical, when to use it, and why the package carries a compatibility caveat. Write that down once; it prevents a second developer from solving the same problem with a different, incompatible approach six months later.

Overall recommendation: conditional approval. Validate the native Nova API gap first — if it does not exist, do not adopt. If it does, adopt on a narrow, non-critical surface, behind a shared abstraction, with a documented fork plan and a Nova-upgrade test gate. The package is cheap to try and cheap to remove; the risk is not adoption, it is forgetting it is there.