Laravel Nova Belongsto Dependency Laravel Package

Technical Evaluation

Architecture fit

• The package is a Nova field-level extension, not an application-layer dependency. It adds a custom BelongsTo field type (PHP field class + compiled Vue component) that makes a searchable relationship select react to the values of sibling fields. There are no migrations, no model changes, and no service-provider-level bindings that would leak into the domain layer.
• Conceptually this is a strong fit for a common admin-panel requirement: cascading selects (Country → City, Client → Project, Tenant → User). Today teams typically hand-roll this with options() closures or custom Vue fields, so a drop-in field is attractive.
• The coupling is entirely to Nova's front-end contract, which is the least stable part of the stack. This is an admin-UI convenience, not a core capability — which is the right risk posture for unvetted community code.

Integration feasibility

• Mechanically simple: composer require, register the field in a Resource's fields() method, swap out the existing BelongsTo. A developer can spike this in under a day.
• Feasibility hinges on unverified compatibility. The repository shows zero stars and zero dependents, which means no production signal, no issue history to mine, and no evidence of maintenance against current Nova releases. Treat it as a code sample, not a supported library.
• Nova ships as a paid, closed-source package with breaking changes across major versions (Vue 2 in Nova 3 vs. Vue 3 in Nova 4/5, changed field meta APIs, changed asset pipeline). Verify the package's composer.json constraint on laravel/nova and whether it ships compiled assets or requires a local npm run dev/npm run prod in vendor/.

Technical risk

• High overall, driven by maintenance and compatibility rather than by design quality.
• Redundancy risk: Nova 4+ natively supports dependsOn() plus closure-based options(), which covers many of these use cases without third-party code. Confirm the package adds behavior the native API cannot express before taking on the dependency.
• Licensing and provenance: confirm the license (likely MIT), review the Vue component source, and scan the JS dependency tree. You are shipping third-party JavaScript into an authenticated admin surface.
• Vendor lock on a paid platform: if Nova upgrades break the field, you cannot escalate to Laravel; you own the fix.

Key questions

1. Which Nova major versions are supported, and what is the exact composer.json constraint? Does it work on our pinned Nova version and PHP/Laravel version?
2. Does it ship pre-compiled assets, and is there a documented build step? Does it require vendor:publish?
3. How does the dependency propagate — does it re-query via Nova's search endpoint on every parent change, and what query parameters does it send?
4. Does it compose with relatable(), viaResource(), withMeta(), and Nova's native dependsOn()?
5. Is there server-side enforcement of the dependency, or is filtering purely client-side?
6. Who maintains it, when was the last commit, and is there any test coverage?

Integration Approach

Stack fit

• Laravel + Nova + Vue. If we are already on Nova and already writing custom fields, the idioms will be familiar. If we are not on Nova, this package is not a reason to adopt it.
• Because Packagist presence is unconfirmed, plan on a VCS repository entry in composer.json or a vendored fork under our own namespace.

Migration path

• Introduce incrementally: one Resource, one field pair, behind a feature branch. Do not do a sweep replacement of existing BelongsTo fields.
• Maintain a documented fallback: native dependsOn() + options(fn ($request) => Model::where(...)->get()) in Nova 4+, or a small in-house Vue field. The fallback should be scoped and estimated before the spike concludes, so the decision is "adopt vs. build" rather than "adopt or stall."

Compatibility

• Pin the Nova version in composer.json and freeze it for the duration of the evaluation. Nova upgrades are the primary breakage vector; a minor Nova bump should trigger a regression test of this field.
• Verify the Vue version in Nova's compiled bundle matches what the package's component was built against. A Vue 2 component in a Vue 3 Nova will fail at runtime, often silently.

Sequencing

1. Spike (1–2 days): install in a branch, wire up one cascading pair, confirm rendering, filtering, and search behavior.
2. Query profiling: capture query counts and endpoint payloads on a realistic dataset with a large option table.
3. Security and license review: read the Vue source, check the license, scan JS dependencies.
4. Validation layer: implement server-side Rule::exists/scoped where rules regardless of package outcome — the field only constrains the UI.
5. Pilot: one internal admin resource, one release cycle.
6. Decide: adopt, fork, or replace with native/ in-house. Re-evaluate at the next Nova upgrade.

Operational Impact

Maintenance

• Effectively we become the maintainers. With zero dependents there is no community to surface breakage, so we must own the compatibility matrix ourselves. Budget a few hours per Nova upgrade for regression testing, more if a fork is required.
• Fork-and-vendor is the realistic end state. Plan for it in the repo structure rather than treating it as a failure.

Support

• No SLA, no vendor. Issues are GitHub-only and may be unanswered. Nova's own support will not assist with third-party fields — expect to debug Vue/Nova internals ourselves.
• Ramp-up for a Laravel developer is low (hours); debugging a broken Nova field bundle is moderate (a day or more) because Nova's compiled assets are opaque.

Scaling

• The dependent-filter pattern multiplies AJAX calls: every parent-field change can trigger a fresh search request. On forms with several dependent fields this is noticeable.
• Ensure the filtered columns are indexed, that searchable fields use indexed columns, and that result sets are bounded. Validate against a production-sized options table, not seed data.

Failure modes

• Silent UI regression after a Nova upgrade — the field renders but stops filtering; users select invalid combinations. Requires a smoke test.
• Client-side-only enforcement — the critical one. Filtering the dropdown does not prevent invalid foreign keys via direct API calls or form replay. Mandatory server-side validation closes this.
• Asset 404 — component not published or built, leaving a broken or empty select.
• Search endpoint load — large unindexed tables causing slow admin forms.
• Fail-open behavior — if the dependency resolution errors, the field may fall back to showing all options, which looks functional but is not.

Recommendation

• Worth a time-boxed spike if cascading selects are a recurring requirement and we are on Nova 4+ without a native solution that fits. Do not adopt as a production dependency in its current state (0 stars, 0 dependents, unverified maintenance) without a fork plan and a named owner.
• Gate production use on: verified Nova version compatibility, a completed license/security review, and server-side validation shipped alongside.