Nova Conditional Fields Laravel Package

Product Decisions This Supports

• Progressive disclosure in admin forms (build vs. buy vs. configure). This package supports the decision to make internal Nova forms adaptive rather than flat: show shipping, billing, or compliance fields only when a parent field (e.g. requires_shipping, entity_type, payment_method) makes them relevant. That is a UX/quality decision you can make once and reuse across resources.
• Scope and complexity of internal tooling. Conditional display lets a single resource serve multiple user roles or workflow states (draft vs. published, individual vs. company, domestic vs. international) instead of building separate screens per persona — a direct reduction in admin surface area to design, test, and maintain.
• Data quality and support-ticket reduction. Hiding irrelevant fields lowers mis-entry rates and "which field do I fill in?" tickets. Frame this as an ops-efficiency bet, not a UI nicety: fewer wrong values in, fewer corrections and manual cleanups downstream.
• Roadmap sequencing for the admin layer. Because the package is WIP and last released in 2019, it is best treated as a reference implementation and spike input, not a dependency you commit to. The decision it informs is "do we invest a small, bounded effort in conditional form logic now, or defer until the resource is rewritten?"
• Feature gating in back-office workflows. Useful for staged rollouts of new fields (show a new field only when a feature flag field is enabled), letting you ship schema changes without a coordinated release.
• Use cases that justify it: KYC/onboarding questionnaires, order fulfillment and returns forms, content publishing workflows, pricing/tier configuration, and any resource where 30–50% of fields are only conditionally applicable.

When to Consider This Package

Consider it when:

• You are on a legacy Laravel Nova version whose field API matches this package's era, or you are prototyping to validate the conditional-field pattern before committing.
• The conditional logic is simple and shallow (one parent field toggles a handful of siblings; no chained or nested dependencies).
• You can vendor or fork the code. MIT licensing and a very small footprint mean the cost of taking ownership is low — you are buying a pattern, not a platform.
• Your form surface is small (a few resources), so re-implementing the logic natively if the package breaks is a contained, predictable effort.
• You have engineering capacity to pin the version, add tests, and treat it as internal code.

Look elsewhere when:

• You are on a current Nova major version. Field APIs have changed materially since 2019; verify compatibility explicitly rather than assuming, and expect to reimplement.
• You need maintained dependencies, security patching, or a vendor who will respond to issues. An unmaintained WIP package is a standing liability on a paid admin platform.
• Your conditional logic is complex (multi-parent rules, cross-field validation, nested conditions) — a general-purpose rules engine, or server-side validation plus a thin UI layer, is the better architecture.
• Accessibility, theming/brand consistency, or localization of conditional behavior is a requirement; a small WIP package will not cover it.
• Conditional visibility alone is insufficient and you actually need conditional validation, required-ness, or persistence — scope that upfront, since hiding a field does not by itself enforce anything server-side.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a tiny, MIT-licensed community add-on for our Laravel Nova admin panel that lets a field appear only when it is relevant — for example, showing shipping details only when an order requires shipping. The business case is efficiency and data quality in internal tooling: simpler forms for ops and support staff, fewer data-entry errors, fewer correction cycles. It is free, low-risk to evaluate, and the underlying pattern is something we would want regardless of vendor. However, the package itself is marked work-in-progress and has not been released since 2019, so we should treat it as a design reference and a short spike, not a long-term dependency on a paid platform that has since moved on.

For engineering (the ask): Run a time-boxed spike (roughly 1–2 days) to evaluate the package against our Nova version and either (a) fork and vendor it with tests if the field API still matches, or (b) reimplement the conditional show/hide behavior natively using our existing field lifecycle hooks. Prefer (b) if there is any doubt about compatibility — the logic is small enough that owning it outright is cheaper than tracking an abandoned dependency. Regardless of path, pair conditional visibility with server-side validation so hidden fields cannot be submitted with stale or invalid values, and add test coverage for each conditional rule so form behavior is regression-safe.

Decision requested: Approve a bounded spike with a default outcome of an in-house implementation; adopt the package only if the spike shows it works unmodified on our Nova version and can be vendored with tests.