Nova Conditional Fields Laravel Package

Technical Evaluation

Architecture fit. dillingham/nova-conditional-fields is a purely presentation-layer add-on for Laravel Nova. It does not touch your domain model, routes, persistence, or authorization surface — it wraps Nova field definitions in a Vue container that watches a sibling field's value and toggles visibility. That makes it architecturally low-risk in the sense that it cannot corrupt your application core, and equally low-value in the sense that it solves one narrow form-UX problem: "hide field B until field A equals X." If your admin surface is built on Nova and you have more than a handful of long forms with irrelevant fields, the problem is real. If you are not on Nova, this package is irrelevant — there is no Filament, Livewire, or Blade-form applicability.

Integration feasibility. Installation is the standard Composer + package-discovery path, MIT-licensed, no service provider gymnastics expected. Adoption cost is measured in hours, not sprints, for a single developer who already knows Nova's field API. The API is declarative (attach a dependency rule to a field and name the controlling attribute), which is the right shape for the problem and matches how Nova developers already think. The real feasibility question is version compatibility, not effort.

Technical risk. This is the dominant concern. The package is self-labelled WIP, last released 2019-02-08, with 38 stars and no evident maintenance since. That places it in the Nova 1.x/2.x era. Nova 3 and especially Nova 4 (Inertia + Vue 3, reworked field component contract) invalidate most pre-2020 field packages. Concretely, expect to validate: (a) the Vue wrapper's mechanism for observing sibling field values still works on your Nova version; (b) hidden fields do not silently retain and submit stale values into your model; (c) required validation rules on conditionally hidden fields do not block submission server-side; (d) compatibility with panels, tabs, File/Image fields, and dependsOn chains. Items (b) and (c) are correctness bugs, not cosmetic ones — a hidden field that still writes is a data-integrity incident, and a hidden-but-required field is a support ticket generator.

Key questions.

• Which Nova major/minor version is in production, and does the package's constraint actually allow it?
• Does the package clear hidden field values on submit, and is that behaviour configurable?
• Is there a server-side counterpart, or does conditional validation still need to be hand-written in rules()?
• Does it handle transitive dependencies (A controls B, B controls C) and cross-panel/tab lookups?
• Is the upstream repository effectively abandoned, and are we prepared to vendor-fork it?
• Has anyone evaluated Nova's native dependsOn support (Nova 3.20+) as a superseding capability?

Verdict. Score 1.60 with 1.14 opportunity reflects the market accurately: a thin, unmaintained, single-ecosystem package. It is a reasonable reference implementation to read before writing your own 100-line wrapper, and a poor dependency to adopt in 2024+.

Integration Approach

Stack fit. Requires Laravel + Nova, Composer, and a Vue-capable frontend build only if you fork. Fits cleanly alongside existing Nova resources; no middleware, migrations, or config publishing expected. Zero impact on API, queue, or persistence layers.

Compatibility. Treat Nova 3+/4 support as unproven until verified. Pin the package in composer.json, install in a branch, and exercise it against a representative resource before it reaches a shared environment. If you are on Nova 4, assume incompatibility and plan accordingly.

Migration path. Three options, in order of preference:

1. Use Nova's native conditional field support where available (Nova 3.20+ dependsOn). This is the lowest-risk path — no third-party surface, values cleared on hide, maintained by the vendor.
2. Build in-house a small trait/field wrapper modelled on this package's approach. MIT license makes reading and reimplementing legitimate; a ~1–2 day spike for a Nova-fluent developer, and you own the semantics for value-clearing and validation.
3. Adopt and vendor-fork the package only if your Nova version is confirmed compatible and the visibility rules are trivial.

Avoid a partial adoption where some resources use the package and others use native/Nova mechanisms — inconsistent hide/clear semantics across forms is itself a defect class.

Sequencing. (1) Version-compatibility spike on a throwaway branch with one real resource. (2) Decide buy-vs-build based on whether hidden-field values are cleared and whether validation behaves. (3) If adopted, pin the version, document the WIP status internally, and add a test resource that asserts hidden values are not persisted. (4) Roll out to the highest-friction admin forms first, measure support tickets, then decide on broader usage.

Operational Impact

Maintenance. Effectively unmaintained upstream. Budget for a fork the moment your Nova version moves — and Nova major upgrades are the precise moment this package will break. Because it is MIT, forking is legally trivial; the cost is the engineering time to keep a Vue component aligned with Nova's field contract, which is non-obvious to anyone who hasn't read Nova's internals.

Support. No vendor, no SLA. Support is your own team plus GitHub issues on an abandoned repo. TPM action: record the owner of this dependency in your service catalogue and add it to the Nova-upgrade checklist.

Scaling. Negligible runtime cost — it is client-side visibility logic on form pages, not a hot path. It does not scale with traffic; it scales with form complexity. The failure mode at scale is organizational: many resources adopting inconsistent conditional conventions, producing admins who cannot explain why a field is missing.

Failure modes.

• Hidden field still submits a stale value → silent data corruption on save.
• Hidden field with required rule → form blocked with no visible field to fix.
• Nova upgrade → fields vanish or throw, with no upstream fix.
• Cross-panel/tab dependency → rule silently no-ops.
• File/Image fields conditionally hidden → orphaned uploads.

Ramp-up. Low for consumers (declarative, one concept). Moderate-to-high for maintainers (Vue field-component lifecycle inside Nova). Net: cheap to trial, expensive to own.

Recommendation. Do not take a production dependency on this package. Use it as a design reference and a short-lived spike artifact; ship conditional fields via Nova's native support or a small in-house wrapper you control. The opportunity score of 1.14 and a 2019 WIP tag are sufficient signal.