Nova Belongs To Dependency Laravel Package

Technical Evaluation

Architecture fit

Laravel Nova's native BelongsTo field supports dependsOn() only for visibility/read-only toggling in the form — it does not re-query or filter the relationship options based on a sibling field's value. This package fills that specific gap by extending the field class and shipping a custom Vue component that reacts to sibling field state (BelongsTo, Text, Status) and reloads its option set. Architecturally it is a thin decorator over a first-party Nova primitive, which is the right shape: no service provider hijacking of Nova internals, no database schema footprint, no event/listener surface. It is a presentation-layer concern only, so blast radius is limited to Nova form rendering.

The caveat is that Nova is a closed-source, license-gated product whose field internals (Vue mixin APIs, dependsOn resolution, relatable query hooks) change across major versions. Any package that extends those internals inherits version-coupling risk that is invisible from the outside.

Integration feasibility

Mechanically trivial: composer require manmohanjit/nova-belongs-to-dependency, publish/compile assets, then swap BelongsTo::make() for the package's field on the handful of resources that need cascading selects. Effort is hours, not days, for a proof of concept.

The real feasibility constraint is provenance, not code. Ten stars, a single maintainer, and an archived repository mean there is no realistic path to upstream fixes, no security response channel, and no compatibility guarantee against Nova 4/5. For a TPM, the correct framing is not "adopt a dependency" but "vendor a ~few-hundred-line field component into our codebase and own it." That changes the calculus favorably — the code is small enough to audit and adopt — but it must be a deliberate fork, not a Composer line item.

Technical risk

• Abandonment (high, realized): already archived. No patches for Nova upgrades; the next Nova major likely breaks it silently.
• Version coupling (high): requires validating against the exact Nova major/minor in use. Nova's changelog is not public in a way that lets you diff field-contract changes ahead of time.
• Custom async endpoints (medium): cascading option loading typically implies an AJAX path. If the package registers its own route, authorization and query scoping must be verified — a dependent-select endpoint that returns unfiltered relationship data is a horizontal privilege leak.
• Frontend asset pipeline (medium): compiled Vue assets must be rebuilt against the project's Nova build; stale published assets are a common silent-failure mode.
• Licensing (low): MIT is clean and permits the fork-and-own approach.

Key questions before any commitment

1. Which Nova major/minor are we on, and does the field's Vue component match that contract?
2. Does the package register any routes or controllers, and if so, what policy/authorization gates them?
3. How does it resolve options — a full relationship query per change, or scoped by the parent value? What is the query cost at our largest table?
4. Do we have a Nova license in CI/local dev to even exercise this, or is testing manual-only?
5. Does the cascade need to work on create and update, including pre-populated edit forms where the parent value is already set?
6. Who owns the vendored fork, and on what trigger do we revisit (Nova upgrade, security review cycle)?

Integration Approach

Stack fit

Fits cleanly into a standard Laravel + Nova stack with no additional infrastructure: no queue, no cache dependency, no external service. It is additive to the admin panel only; public application code, APIs, and data models are untouched. This keeps the change reversible — reverting is deleting a field class and reverting resource files.

Migration path

Do not install as a versioned Composer dependency. Instead:

1. Copy the field class and Vue component into app/Nova/Fields/ and resources/js/nova/ (or equivalent), namespaced to us.
2. Pin to the Nova version in use and add a header comment recording provenance (repo URL, commit SHA, license) for auditability.
3. Strip or replace any registered routes with an explicit, policy-guarded controller in our own codebase.
4. Keep the public API (dependsOn(), field chaining) identical so resource files read naturally and can be migrated back if an upstream replacement emerges.

Compatibility

Validate against the specific Nova version first — this is the gating check, not an afterthought. Confirm: field renders on index/detail views or is form-only; dependsOn chains of length >1 resolve correctly; nullable parent values produce an empty-but-valid state rather than an error. Also confirm behavior under Nova's rules() and nullable() constraints, since dependent selects frequently interact badly with validation when the parent changes after the child was set.

Sequencing

1. Spike (1–2 days): fork, install on a scratch resource, prove the cascade works on create and edit against current Nova. Kill the initiative here if it does not.
2. Reference implementation (3–5 days): one real admin resource, with authorization on the option endpoint and a query-cost measurement.
3. Rollout: remaining resources in batches, each with a manual QA pass on create/edit/pre-populated states.
4. Documentation: internal README stating the fork's ownership, upgrade checklist, and known limitations — this is what prevents the next team from re-adding the Composer package.

Operational Impact

Maintenance

Effectively zero upstream maintenance and non-zero internal maintenance. Budget a small but permanent tax: every Nova upgrade requires re-testing the field, and roughly an afternoon of remediation per Nova major. Contrast this with the alternative — a bespoke cascading-select built in-house — which costs more upfront (days) but has no provenance ambiguity and can be designed against the target Nova version rather than reverse-engineered from an abandoned one.

Support

No vendor, no community of scale, no issue tracker that will respond. Support is entirely internal. This is acceptable only because the surface is narrow (form rendering) and the failure mode is visible (broken dropdown) rather than silent (corrupt data). If the cascade ever touched write paths or validation-critical logic, the calculus would change materially.

Scaling

Two scaling vectors matter. First, option-set size: if the dependent field loads hundreds of records per parent change, latency and DB load grow with admin usage, not user traffic — usually tolerable, but worth measuring on the largest relationship (e.g. a child table in the millions). Second, concurrency on edit forms: if two admins edit the same record with dependent selects, there is no additional risk beyond Nova's baseline optimistic behavior, but stale options after a parent change can cause a user to save a now-invalid relationship unless validation re-checks it server-side. Server-side validation must be authoritative; the client cascade is a UX affordance only.

Failure modes

• Parent field cleared → child retains a stale value that passes no validation, producing a dangling reference.
• Nova upgrade → component fails to mount, select renders empty, admins silently cannot create records of that type.
• Asset publish missed in deploy → works locally, blank in staging/production.
• Option endpoint unauthorized → relationship enumeration across tenants; highest-severity failure and the one to test explicitly.
• Unscoped queries on large tables → admin form timeouts that look like infrastructure incidents.

Ramp-up

Low for Laravel/Nova-fluent engineers: the field's public API mirrors BelongsTo, so resource code is self-explanatory and a mid-level developer can use it after reading one example. The ramp-up cost is concentrated in the upgrade path — whoever next touches Nova must understand that this field is a vendored fork, not a package, and that it needs manual re-validation. That knowledge must live in a README, not in someone's head.

Overall verdict: technically sound for a narrow problem, but the archived status and single-maintainer risk make it inappropriate as a live dependency. Forking the small codebase, guarding any custom endpoint, and scoping rollout to one or two admin resources yields most of the value at acceptable lifetime cost. Do not adopt it anywhere the cascade is load-bearing for data integrity.