Nova Dependable Panel Laravel Package

Product Decisions This Supports

• Conditional form UX in Laravel Nova admin surfaces: this package makes panels and fields reactive — showing or hiding them based on the current value of another field (a select, toggle, checkbox, etc.). It directly supports product decisions like "should we gate this configuration block behind a mode switch?" without building custom Vue components in Nova.
• Build vs. buy for internal tooling: the alternative is hand-rolling dependent-field logic (custom Nova fields, Vue components, watch/event wiring, and the maintenance that follows). This package is a small, single-purpose dependency that removes that build cost for internal admin panels.
• Scoping decisions about where complexity lives: it lets the PM choose to model branching logic in the admin UI (progressive disclosure) rather than splitting one resource into several, or adding server-side validation branching. That's a product/UX trade-off, not just an engineering one — fewer fields visible to operators reduces misconfiguration and support load.
• Roadmap signal for "admin experience" work: cheap to adopt, so it is a low-risk enabler for initiatives like onboarding/config wizards, plan- or tier-dependent settings, and multi-tenant feature flags surfaced to ops teams.
• Release 1.2.3 specifically: a patch-level fix for array-key handling in dependent-field evaluation. This is a reliability fix, not a capability change — it supports a decision to keep using / adopt now the package in flows where the controlling field holds an array value (multi-select, checkbox lists, tag inputs). If your dependency logic only reads scalar fields, this release changes nothing for you.

When to Consider This Package

Consider it when:

• You are on Laravel Nova — this is a Nova-specific package and has no value outside that ecosystem. Confirm your Nova license and major version are compatible before committing.
• Your admin UI has genuine branching logic: fields that are only relevant given another field's value, and where showing everything at once causes operator error or confusion.
• The controlling field's value is available client-side (selects, toggles, radios, and array-valued inputs).
• You want this behaviour without maintaining custom Vue/Nova field code — i.e., you'd rather take a small third-party dependency than own the maintenance.
• You can tolerate the support profile of a single-maintainer package (Formfeed-UK). Acceptable for internal tooling; weigh carefully for anything customer-facing or long-lived.

Look elsewhere when:

• You are not on Nova, or you're evaluating a move off Nova — treat this as sunk-cost tooling and avoid deepening the dependency.
• The conditional logic must be authoritative (security, billing, entitlement). Client-side show/hide is presentation only; enforcement belongs in policies, validation, and the domain layer. Do not let this package become the gatekeeper.
• You need dependency rules that span across resources, pages, or wizard steps — this is panel/field-level within a form.
• Your rules are highly dynamic (driven by server-side data, permissions, or computed state). Evaluate whether the package's declarative approach covers it before adopting; otherwise a custom field may be the honest answer.
• The team cannot absorb an extra dependency or requires SLA-backed support.

How to Pitch It (Stakeholders)

To executives (one line): A small, free add-on for our admin panel that hides irrelevant fields until they matter — it makes internal tools faster to use and cheaper to build, with no customer-facing surface area and no licensing cost. Latest patch (1.2.3) is a bug fix, not a new commitment.

To engineering / platform leads: This is a narrow Nova package that provides reactive, value-driven panel visibility. Adopting it replaces bespoke Vue field work with a declarative dependency — less code we own, but a dependency we don't control. It's single-maintainer, patch-only maintenance cadence, and the 1.2.3 release is a fix to array-key handling when the controlling field holds an array (multi-select/checkbox inputs), so it improves reliability in exactly those flows and introduces no API or behaviour change.

Risks to state plainly:

• Presentation-layer only — it must never be the enforcement point for permissions or entitlements.
• Single-maintainer project; pin the version, and have a fallback plan (custom field) if it goes stale.
• Nova version coupling: any Nova upgrade is a re-validation checkpoint.

Recommendation: Low-risk, low-cost adoption for internal admin UX where branching fields exist. Proceed at patch 1.2.3 if array-valued controlling fields are in scope; otherwise 1.2.2 → 1.2.3 is a routine bump. Pair adoption with a one-line note in the codebase that all conditional logic here is cosmetic and must be mirrored server-side.