Nova Dependency Container Laravel Package

Technical Evaluation

Architecture fit epartment/nova-dependency-container is a pure Nova-layer package: a container field that wraps child fields and conditionally renders them based on the values of sibling fields. It registers a Vue component and a PHP DependencyContainer field class, with no migrations, no service-provider domain logic, no queue or storage footprint. It composes with Nova's existing fields() builder, so it slots into the resource layer without touching application architecture, domain models, or API surfaces. For a Nova 3 estate, this is a natural fit — it expresses conditional form logic declaratively instead of scattering ->hideWhen()/custom Vue work across resources. The 1.3.3 fix extends that fit to fieldsForIndex and fieldsForDetail, so the same container definition can now be reused across form, index, and detail contexts rather than being confined to forms.

Integration feasibility composer require epartment/nova-dependency-container plus usage inside fields() is the whole install. Two friction points: (1) Nova is a commercial package and is typically not declared as a hard composer dependency, so CI and local resolution need Nova credentials configured; (2) the package is only as good as the discipline around it — dependency definitions live in PHP resource files, but the enforcement is client-side Vue. Any developer can add it in an afternoon; keeping it coherent across 20 resources is the actual work.

Technical risk

• Version drift is still the headline risk, and 1.3.3 sharpens rather than resolves it. The release explicitly targets Nova 3.x. That is a useful signal — the maintainer is alive and the 3.x line is being patched — but it also confirms the package has not been ported to Nova 4/5. A Vue 2-era compiled asset is likely to break or behave inconsistently on Nova 4/5, and pre-compiled assets mean you cannot patch without forking. If the estate is Nova 4+, this package remains strategically redundant and should be evaluated against native dependsOn() rather than adopted.
• Client-side-only enforcement. Hiding a field in Vue does not change PHP validation. Conditional rules() must be authored separately, and divergence between the visual dependency graph and the server-side rules is the most likely source of bad data.
• Submission semantics. Fields removed from the form by v-if are not submitted; on update this can null out or overwrite previously stored values depending on how the resource's save/fill behaves. This needs explicit testing, not assumption.
• Index/detail was a latent bug, now patched — treat it as a reminder. The 1.3.3 fix implies the container previously misbehaved in fieldsForIndex/fieldsForDetail. Any resource that defines dependency containers there should be re-verified on the new version; conversely, teams that had worked around it can drop the workaround.
• Bus factor. Single maintainer. The 1.3.3 patch shows the project is not abandoned, but there is no cadence to rely on. Still treat it as vendored code you own, not a supported dependency.

Key questions

• Which Nova major version is in production, and does the package's composer constraint even resolve against it?
• Does native dependsOn() cover our requirements (equality-only conditions, single-level nesting), making this package unnecessary?
• Who owns the server-side mirror of every dependency rule, and where is that convention documented?
• Do we have requirements for multi-condition, nested, or relational-field dependencies that exceed the package's model?
• Do we use (or want to use) dependency containers in fieldsForIndex/fieldsForDetail, and if so, does 1.3.3 resolve the previous workaround?
• Do we have Nova license credentials wired into CI and image builds?

Integration Approach

Stack fit Assumes a Laravel + Nova 3 stack on PHP 7.4/8.x. No database, cache, or infrastructure changes; no impact on API or non-Nova code paths. Deploys with the application.

Migration path

• Greenfield forms: adopt directly, but wrap usage in a small internal helper or base resource class so replacing it with native dependsOn() later is a single-file change rather than a sweep across resources.
• Retrofit: replace ad-hoc hideWhen/custom Vue conditionals one resource at a time, starting with the highest-change-frequency forms where conditional bugs actually cost support tickets.
• Index/detail: if dependency containers are used in fieldsForIndex/fieldsForDetail, take 1.3.3 — it is the targeted fix. Remove any local workarounds rather than stacking them on top.
• Exit path: plan the migration to Nova-native conditional fields as part of the next Nova major upgrade, not as a separate project.

Compatibility Pin the package version explicitly; do not float. Verify against the installed Nova release in staging with real resource forms, including a create and an update path, before any rollout. The 1.3.3 fix also means the verification matrix should include index and detail views, not just forms — a gap in the previous plan. Check the compiled asset actually loads on the target Nova build (browser console clean, container renders). If the estate is already on Nova 4+, run the native-feature comparison first and expect to skip this package.

Sequencing

1. One-to-two-day compatibility spike against the current Nova version — this is a go/no-go gate.
2. Proof of concept on a single representative resource, covering create, update, validation failure, partial-submission, index, and detail cases.
3. Codify conventions: where dependency rules live, how server-side rules() mirrors them, how nullable/hidden values are handled, and which resource methods may use the container.
4. Roll out to remaining resources in priority order.
5. Log the fork-and-own decision and the migration trigger (next Nova major).

Operational Impact

Maintenance Assume ownership. MIT licensing is clean for legal/SCA purposes, and 1.3.3 is welcome evidence that the maintainer responds to issues — but there is still no release cadence to ride. Budget a small, recurring allowance for: patch review on Nova upgrades, potential fork to rebuild the Vue asset for Vue 3, and periodic check that upstream hasn't gone quiet. Put it on the dependency watchlist with an annotation reflecting current reality: "low-activity, single-maintainer, Nova 3-only — fork-and-own intent."

Support No vendor support. Issues are community-only and intermittent. Mitigate with an internal runbook: how the container works, the per-resource dependency graph, the validation-mirroring rule, and known pitfalls — including the pre-1.3.3 index/detail behaviour, so anyone still on an older pin recognises the symptom.

Scaling Runtime cost is negligible — it is client-side rendering on admin forms and index/detail tables, not a request-path concern. Scaling pressure is complexity, not throughput: conditional combinatorics grow faster than field count, and deeply nested containers become hard to reason about and debug. Set a convention ceiling (e.g. one level of nesting, equality conditions only) and push anything beyond it into custom fields or resource splitting.

Failure modes

• Hidden fields silently omitted from submission, nulling or staling stored values on update.
• Validation rules firing on invisible fields, producing errors users cannot see or fix.
• Nova upgrade breaking the compiled asset: blank panel, JS errors, or silently non-conditional forms — the worst case, because it fails open and looks fine until data is wrong.
• Conditions on relational or asynchronously-loaded fields behaving unpredictably at render time.
• Nested container recursion or conflicting conditions producing fields that can never be shown.
• Rendering differences between form, index, and detail contexts — the class of bug 1.3.3 addressed. Pin the version and re-verify all three contexts on any bump.

Ramp-up Low for anyone with Nova experience — measured in hours, since the mental model mirrors Nova's field composition. The real onboarding cost is the internal convention: developers must learn that visibility is cosmetic and validation is their responsibility. Add one paragraph to the resource-development guide and one worked example; that is sufficient for a competent Laravel team.