- What does izi-dev/nova-conditional-field do?
- It is a Laravel Nova custom field package that lets you show or hide form fields based on the value of another controlling field in the same resource. You wrap the dependent fields in a conditional container and declare which field drives the visibility. The package adds no database migrations, no persistence layer, and no request lifecycle hooks, so its architectural footprint is small.
- How do I install izi-dev/nova-conditional-field?
- Installation is a standard Composer require followed by registration of the field in your Nova resource. If the package ships compiled JavaScript separately, you may also need to run the Nova publish and asset build steps. There are no external services, API credentials, or infrastructure dependencies involved, so setup is typically under a day for an experienced Nova developer.
- Does Laravel Nova already support conditional fields natively?
- Yes. Laravel Nova 4 and later ship a native dependsOn() API that handles conditional display and can also clear dependent field values when the controlling field changes. For teams on a current Nova release, this package is likely redundant and should be evaluated against the platform primitive first. The package has a defensible niche mainly if you are on Nova 3 or need behavior the native implementation does not cover.
- Which Laravel, PHP, and Nova versions does this package support?
- The package is built as a Nova custom field, so compatibility is bound to Nova major versions, which have historically broken custom fields. Nova 3 uses Vue 2 and Nova 4+ uses Vue 3, so the front-end build must match your Nova major version. Check the latest release metadata against your Nova, Laravel, PHP, and Node versions before committing, since adoption is very low and compatibility claims are not widely validated.
- Does hiding a field with this package also protect it from being submitted or validated?
- No. Conditional visibility is a UI affordance only, so hidden fields can still be submitted and server-side validation still runs. Treating 'the field is hidden' as 'the field is protected' is an authorization design defect that this package will not detect for you. If a field must be blocked, enforce that in your validation rules, policies, or model layer instead.
- Does the package clear dependent field values when the controlling field changes?
- That depends on the implementation and should be verified before adopting it. Some conditional field packages only hide fields client-side and leave stale values in the form payload, which can reach the database on submit. Test this explicitly with a controller change scenario, and if it only hides fields, clear the dependent values yourself in your Nova resource or model logic.
- Is izi-dev/nova-conditional-field safe to use in production?
- Its engineering risk is low but its supply chain risk is significant. The package has roughly 16 GitHub stars and zero Packagist dependents, meaning little to no production validation outside the author's own use, and edge cases like nested or repeatable layouts, file fields, and relationship fields are unlikely to have been exercised. It is a single-maintainer project with a bus factor of one, so plan for it to become unmaintained at an arbitrary point and decide who owns a fork.
- What are the alternatives to this package for conditional fields in Nova?
- The primary alternative is Nova's built-in dependsOn() API, which covers conditional display and value clearing for most use cases on Nova 4 and later. Another option is writing a small custom Nova field yourself, which keeps the dependency surface inside your own codebase and avoids abandonment risk. Given the package's very low adoption, a build-versus-buy check against the native primitive is the recommended starting point.
- Is the package still maintained and will it support future Nova releases?
- There is no strong ecosystem signal that it is actively maintained, and a single maintainer with no downstream consumers is unlikely to prioritize a Nova 5 upgrade, a Vue 3 migration, or a security patch. Because Nova is a paid, closed-source product, you cannot patch the host side yourself if a Nova major release breaks the custom field contract. Confirm whether it has been updated since the last Nova major release and define a remediation SLA before adopting it.
- How should I test a Nova resource that uses conditional fields?
- Prototype a single resource first and verify the controlling field toggles visibility correctly for each field type you plan to use, including relationship and file fields. Then test what actually gets submitted when a field is hidden, so you know whether stale values can reach the database. Finally, add server-side validation tests for any rule that must hold regardless of whether the field is visible, since client-side hiding is not a security control.