Nova Dependency Container Laravel Package

Technical Evaluation

Architecture fit. iamgerwin/nova-dependency-container is a Laravel Nova field add-on: a wrapper field that conditionally shows/hides or enables/disables child fields based on the value of other fields. Architecturally it is a thin, additive layer — a custom Nova Field subclass on the PHP side plus a Vue component on the Nova front-end. It does not alter application domain code, routing, persistence, or the service container beyond a single service provider. For teams already standardized on Nova, this is a low-coupling fit; for teams not on Nova, the package is irrelevant (Nova is a paid, closed-source first-party product).

Integration feasibility. High. Composer install with Laravel package auto-discovery; usage is declarative inside Nova::resources() field definitions. v1.0.16 is a patch release with no public API, schema, config, or field-definition changes — the surface area a consumer touches is unchanged. The one behavioral change worth noting is defensive: FieldServiceProvider now guards Nova asset registration behind a class_exists check, so the package no longer hard-fails in environments where Laravel\Nova\Nova is absent.

Technical risk.

• Low: upgrade risk from v1.0.15 — additive guards, dependency bumps, debug-log removal only.
• Low–medium: Nova version coupling. The front-end is a Vue component; Nova's Vue major version and asset pipeline have changed across Nova 4 → 5. The release notes do not state a tested Nova compatibility matrix, which is the single most important unknown for a production upgrade.
• Low: the new Nova-absence guard could convert a hard failure into a silent no-op. If a production deploy is misconfigured (Nova not autoloaded), the symptom shifts from a loud boot error to a missing/blank field. This is the right trade-off for CI, but it needs an explicit assertion in staging.
• Low: PHP 8.5 is asserted as supported; 8.5 is not yet generally available. Treat as forward-looking, not a validated target.
• Low: bus-factor. Single-maintainer package with a small footprint — acceptable because the blast radius is one Nova field wrapper and the code is forkable.

Key questions for the maintainer / internal owners.

1. What is the tested Nova compatibility matrix (Nova 4.x / 5.x, Vue 2 vs Vue 3)?
2. Does the class_exists guard log a warning when Nova is absent, or fail silently? Can it be made to fail loudly outside local/testing?
3. Is the ~9% JS bundle reduction (27.2KB → 24.7KB) measured pre- or post-minification, and does it include the Vue runtime or only the field component?
4. Are the Pest 3.7.4 / collision ^8.6 bumps floor-only, and do they raise the minimum Laravel version transitively?
5. What is the support/response expectation for the repo, and do we need a pinned fork policy?

Integration Approach

Stack fit. Requires Laravel (auto-discovery era), PHP 8.3+, and a licensed Nova installation. If the platform is on PHP 8.1/8.2 today, this release effectively raises the floor — that is the only potentially gating item in the changelog, and it should be validated against the platform's supported PHP matrix before upgrading.

Migration path. Straightforward composer update iamgerwin/nova-dependency-container from ^1.0.15 to ^1.0.16. No migrations, no config publish, no field-definition edits, no asset republish required in the normal case (Nova's nova:publish/nova:assets step should still be run if the project vendors assets). No codemods, no deprecations to chase.

Compatibility. Confirm three axes before merge: (a) platform PHP version ≥ 8.3; (b) Nova major version matches what the package's Vue component targets; (c) transitive floors from collision ^8.6 and pest ^3.7.4 are dev-only and do not constrain production composer.lock. The PHPStan-clean claim plus passing tests raises confidence that the Nova-absent path is now exercised in CI — verify that the suite actually runs without Nova in at least one job.

Sequencing.

1. Update in a non-production branch; run the full test suite in a Nova-less CI job to confirm the new guard behaves.
2. Deploy to a staging environment with Nova present; smoke-test two or three representative dependency-container field definitions (show/hide, enable/disable, nested/multi-level dependencies) and confirm browser console is clean post-deploy.
3. Verify asset publication and cache-busting — the JS bundle changed, so stale published assets are the most likely cosmetic regression.
4. Promote to production on a normal release cadence; no maintenance window needed.

Operational Impact

Maintenance. Near-zero steady-state. No scheduled jobs, no queues, no storage, no external services, no configuration to drift. The only recurring task is bumping the pin alongside Nova major upgrades, since that is when the Vue component contract is most likely to break.

Support. Support load is concentrated in Nova upgrades and front-end asset issues, not in day-to-day operation. Because Nova is closed-source and the package is community-maintained, internal teams should budget the ability to read and patch ~a few hundred lines of PHP/Vue rather than depend on upstream turnaround. Recommend pinning to ^1.0.16 and treating it as an "evaluate on upgrade" dependency rather than auto-merging renovator PRs, given the Nova/Vue coupling.

Scaling. Effectively free at runtime: the field logic is client-side condition evaluation over already-rendered form fields, invoked on value change. No per-request database or network cost, no server-side evaluation. Performance impact is bounded by the number of dependency containers on a given Nova form — worth a sanity check on very large resource forms (dozens of containers), where per-keystroke reactive evaluation could add up. The 2.5KB bundle reduction is negligible on its own but directionally good.

Failure modes.

• Stale published assets after upgrade → field renders with old component behavior or none at all. Mitigate by republishing assets and clearing the Nova cache in the deploy step.
• Silent no-op when Nova is unavailable (new in this release) → blank or always-visible fields instead of a boot error. Mitigate with a post-deploy assertion that a known dependency container renders and toggles correctly.
• Nova major upgrade breaks the Vue contract → fields render but dependencies stop evaluating. Mitigate by pinning Nova and gating Nova upgrades on a manual field regression pass.
• PHP floor mismatch → hard composer resolution failure, caught pre-deploy; low residual risk.
• Abandoned upstream → package stops tracking Nova. Mitigate by forking into an internal namespace if the dependency count on Nova forms grows.

Ramp-up. Minimal for any Laravel developer already fluent in Nova: the API is declarative field composition, learnable in under an hour from the README plus one example. The real ramp-up cost is environmental — getting a developer to a working Nova install locally (paid license, asset build). The improved Nova-absence handling in v1.0.16 partially reduces this by letting contributors run the package's own tests without a Nova license, which meaningfully lowers the cost of contributing a fix or verifying a patch. Recommend documenting the expected field behaviors (visible / hidden / enabled / disabled / nested) in the team's internal Nova conventions doc so regressions are caught by inspection rather than by QA.