Nova Belongsto Depends Laravel Package

Technical Evaluation

Architecture fit. The package is a Nova field extension: it subclasses Laravel Nova's BelongsTo field and ships a matching Vue form component to implement cascading (parent → child) option loading in the admin UI. Architecturally this is a thin, single-purpose plug-in that lives entirely inside the Nova presentation layer — it does not touch domain models, migrations, or application services. For a Laravel/Nova codebase that already depends on Nova as the back-office surface, the conceptual fit is good: it is additive, scoped to specific resources, and reversible. The caveat is that it extends Nova internals (field resolution, Nova::script/asset registration, Vue component contracts) rather than a stable public API, so "fit" is contingent on Nova major version parity.

Integration feasibility. Installation is trivially cheap — a Composer require plus field usage in a _fields() method, with no schema changes and no data migration. The real feasibility question is not effort but version compatibility, since Nova 3 (Vue 2, Laravel Mix) and Nova 4+ (Vue 3, Vite/Tailwind rewrite) are materially different component contracts. A package at 2 stars and 0 dependents almost certainly targets a single Nova generation and was not regression-tested against newer majors. Feasibility is therefore high for a spike and conditional for production.

Technical risk. High relative to the value delivered:

• Maintenance signal is effectively zero — 2 stars, 0 dependents, no ecosystem validation, no evidence of CI or test coverage. Bus-factor of one.
• Deep coupling to a paid, fast-moving host — a Nova upgrade can silently break the field.
• Behavioral surface is under-specified — unclear whether dependent options are fetched via AJAX routes, injected at render time, or derived client-side; this determines query cost, authorization behavior, and cacheability.
• Supply chain — MIT-licensed and small, so vendoring/forking is viable, but no third-party audit trail exists.
• The low composite score (1.05) is consistent with "unmaintained micro-package," not "broken package."

Key questions to resolve before commitment.

1. Which Nova major versions are supported, and what is the composer.json constraint? Does it work on our current Nova and Laravel/PHP versions?
2. Are dependent options loaded server-side per parent selection, or hydrated client-side? What is the resulting query count per form render?
3. Does it respect Nova authorization/policy scoping on the related resource, or does it bypass it?
4. Does it support searchable, relatable query callbacks, nullable parents, and multi-level chains (>2 levels)?
5. Is the repository archived or merely dormant — and are we willing to fork and own it?

Bottom line: treat this as reference source code, not a dependency. The implementation is small enough that the realistic play is a 1–2 day spike to evaluate, then either vendor/fork it with internal ownership or reimplement the behavior as a first-party Nova field.

Integration Approach

Stack fit. Requires Laravel + Nova (commercial license) on the standard Composer/ServiceProvider auto-discovery path. No database, queue, or infrastructure footprint. Fit is cleanest in a monolith where Nova is the only admin surface; it is a poor fit where Nova is being phased out or where an API-first admin (Filament, custom SPA) is the direction of travel. Confirm the front-end asset pipeline matches our Nova build (prebuilt assets vs. requiring npm run dev), since that alone can turn a "composer require" into a build-tooling project.

Migration path. Two viable paths, both low-cost:

• Adopt-and-pin: install at an exact version, wrap it in an internal field class (e.g., App\Nova\Fields\DependentBelongsTo) so call sites never reference the vendor class directly. This makes a later fork or swap a one-file change.
• Reimplement: Nova's built-in dependsOn() handles field visibility by parent value, not option filtering. If our need is only visibility, we need no package at all. If we genuinely need cascading option sets, a first-party field (~200–400 LOC including the Vue component) is a credible and often preferable path.
• No data migration is required either way; existing records keep their FK values. Rollback is deleting field usage.

Compatibility. Gate on a written compatibility matrix: Nova version × Laravel version × PHP version × Node/Vue generation. Test in a staging Nova instance with representative resources. Pin the dependency exactly in composer.json (no caret range) to avoid silent drift, and add a lockfile-diff check to code review.

Sequencing.

1. Discovery (0.5 day): read the source, confirm mechanics, extract the compatibility matrix and the answers to the key questions above.
2. Spike (1–2 days): wire it into one low-risk resource in a staging branch; measure query counts, verify authorization scoping, test with empty/null parents and >2-level chains.
3. Decision gate: adopt-and-pin vs. reimplement. Bias toward reimplement if any key question is unanswered or if we are not on the package's supported Nova major.
4. Pilot (1 resource): ship behind the internal wrapper class to one admin screen with a named internal owner.
5. Rollout: expand resource-by-resource; document the wrapper and the fork point in the platform runbook.

Operational Impact

Maintenance. Effectively zero upstream maintenance to rely on. The package should be treated as frozen source: vendored or forked into an internal namespace, with the fork recorded in the dependency register and assigned an owner. Because the surface is small, the ongoing cost is not patching — it is the latent cost of a Nova upgrade discovering the break in production. Budget a recurring line item for "verify custom Nova fields against each Nova major."

Support. No vendor, no SLA, no issue-triage capacity worth counting on at 2 stars. All support is internal. Ensure the adopting team can read Vue and Nova's field internals, or the package becomes an orphan the moment the original developer rotates off.

Scaling. Risk is concentrated in option loading, not in traffic volume:

• If dependent options are fetched per parent selection, each form render can add round trips and queries. On resources with large related tables this becomes an N+1 and latency problem at admin scale.
• Mitigate by constraining related queries (indexed FK columns), caching reference datasets where they are slow-changing, and validating query counts in the spike.
• Admin concurrency is typically low, so throughput is not the constraint — response time per form is.

Failure modes.

• Silent breakage on Nova upgrade: component fails to register, field renders as a plain select or empty dropdown; no error surfaced to users. Detect via a smoke test on a representative resource post-upgrade.
• Empty or wrong option sets: stale cache, changed parent value without child reset, or an unscoped query returning unauthorized records.
• Authorization bypass: dependent options exposing records the policy would otherwise hide — verify explicitly; this is the highest-severity failure mode.
• Asset/publish collisions: published Vue assets conflicting with other custom fields or Nova's build.
• Abandonment drift: the fork diverges from upstream with no merge path — acceptable if we accept permanent ownership at fork time.

Ramp-up. Low for any developer already fluent in Laravel + Nova field authoring: a half-day to be productive, dominated by understanding Nova's field/component contracts rather than this package. Teams without Nova-internals experience should expect 2–3 days and should not be the ones owning the fork. Documentation burden is minimal but non-zero: record the wrapper class, the supported version matrix, and the upgrade-verification checklist in the platform runbook.