Nova Dependency Container Laravel Package

Product Decisions This Supports

• Progressive disclosure in internal admin tools — the cheapest UX lever available. The package's whole job is group-level conditional rendering: wrap a block of Nova fields in a DependencyContainer and declare ->dependsOn('plan', 'premium'); the block appears or disappears reactively as the operator changes the parent field. For the ops, support, and finance teams who live in Nova daily, that reduces clutter and mis-entry — with no migration, no data model change, and no front-end project. When the backlog item reads "our admin forms are too long and people pick the wrong option," this is the lowest-cost response on the table.

• A build-vs-buy call that resolves cleanly toward buy. The alternative is a bespoke Vue field component: engineering time, a build step, a component nobody else on the team understands, and re-validation on every Nova upgrade. This is a small, MIT-licensed, declarative wrapper that substitutes for that work. Frame it internally as "adopt, pin, and treat as vendorable code" — not "staff a small project." It's small enough to decide at the team level without climbing a roadmap prioritization ladder.

• Roadmap sequencing for admin-tooling milestones. Conditional field visibility is a recurring blocker when modeling tiered or polymorphic entities — plans, regions, feature flags, pricing rules, person-vs-company records. Having it as a reusable primitive unblocks several admin screens in parallel instead of gating each behind custom work, which lets you commit to admin-tooling dates with less padding.

• Scoping "dynamic forms" honestly, before it becomes scope creep. When a stakeholder asks for dynamic forms, this covers the show/hide case cheaply and draws a boundary you can point at later: it is presentation-layer dependency — not conditional validation, not conditional persistence, not conditional authorization. Naming that boundary up front is itself a product decision, and it heads off the follow-on assumption that "hidden" means "not required," which is the defect this package most reliably produces if left unmanaged.

• A vendor-risk call made at the package level, not the platform level. One maintainer, 46 stars, zero dependents, last release March 2025. That is a deliberate judgment about acceptable maintenance exposure: classify it as a forkable leaf dependency and never as infrastructure. MIT makes the fallback — fork into an internal registry — cheap and legally uncomplicated, and that cheapness is exactly what makes the risk tolerable. Deciding it once, explicitly, stops it being re-litigated at every sprint planning session.

• A forcing function for a house rule on conditional validation. The package hides fields visually but does not stop Nova from validating, resolving, or persisting them. Adopting it means the team must settle, once, what "required" means for a hidden group (Rule::when, sometimes, nullable defaults). That artifact is the highest-leverage output of the whole effort — it converts a per-resource judgment call into a review checklist and pays for itself across every subsequent resource.

When to Consider This Package

Adopt when most of the following hold:

• You are on Laravel Nova 4 and locked there. Verify against your exact Nova minor before committing — the package hooks Nova's internal form-field layer, and those internals shift between releases. A pinned Nova major is a hard prerequisite, not a nice-to-have.
• The need is genuinely group-level visibility. Nova's built-in dependsOn already handles single fields. The gap this fills is showing and hiding a container of several fields together. If your use case is one field depending on another, you don't need this.
• Your team has no appetite to own a custom Vue component — or already owns too many and the maintenance ledger is full.
• The surfaces are internal admin screens. Blast radius matters: the worst case is a field rendering wrong, not data corruption. Do not put this in front of customers or in a compliance-critical workflow without additional backend enforcement.
• You can pin the version, read the source, and fork if needed. The codebase is small and the license permits it. Teams without the capacity to read a small package and vendor it should treat this as unsupported software and plan accordingly.
• The conditions are shallow. One or two levels of dependency, keyed off one or two parent fields. This is where the package is genuinely pleasant.

Look elsewhere — or hold — when:

• You are on Nova 5, or upgrading within the planning horizon, and compatibility isn't confirmed. Treat Nova 5 readiness as unresolved, not assumed: either budget the fork or defer adoption until a spike closes it.
• You need conditional validation, persistence, or authorization. Hidden fields are still processed by Nova's rules and by resolve/fill. Real business rules belong in the backend where they can't be bypassed via the API. This package is a rendering aid only.
• You need a supported, SLA-backed dependency. One maintainer means you are effectively self-supporting. Budget roughly 4–8 hours per Nova upgrade cycle plus a standing "is it still maintained?" check — and be honest that this is an ongoing line item, not a one-time integration.
• You're on Filament or another admin framework with native dependent fields. No reason to introduce Nova-specific code into a non-Nova stack.
• The genuine requirement is a multi-step or wizard flow. Hiding and showing groups is a poor substitute for real form architecture. Multi-level conditional forms get hard to reason about, hard to test, and hard to hand off — the cost is cognitive, not technical.

How to Pitch It (Stakeholders)

For executives: This is a small, free, MIT-licensed add-on for our existing admin tool. It lets admin forms show only the fields that apply to the choice an operator has made — select "Premium" and the billing fields appear; select "Basic" and they don't. It replaces what would otherwise be a custom front-end build we'd own and re-validate on every upgrade. The cost is near zero; the risk is a field rendering incorrectly on an internal screen, not data loss. We mitigate by pinning the version and keeping the fork option open, which the license makes cheap.

For engineering: Treat this as a forkable leaf dependency, not infrastructure. Pin the package version, constrain the Nova major in composer.json, and depend on nothing else about its behavior. Expect roughly 4–8 hours per Nova upgrade cycle to re-verify, and treat Nova 5 readiness as an open question until a spike proves it. Two non-negotiables in code review: reference watched attributes via constants shared with the parent field — a typo'd attribute fails silently and only a reviewer catches it — and pair every container with conditional validation (Rule::when), because hidden fields are still saved and validated. Debug via the edit endpoint's JSON meta payload rather than the browser; that separates "wrong config" from "component not registered" in one step. Keep containers presentational: no rules, defaults, or resolveUsing on the container — those belong to the field that owns the value.

Ask: Approve adoption on one non-critical resource as a go/no-go, then a second resource with different field types to prove the pattern generalizes. Hold broader standardization until the Nova 5 question and the vendoring decision are settled.