Nova Belongs To Dependency Laravel Package

Product Decisions This Supports

• Feature scoping for admin/back-office UX. The package delivers cascading dependent BelongsTo selects (Country → State → City, Client → Project → Task) declaratively — one field class plus a dependency method — instead of hand-built Vue components. That lets a PM put "context-aware dependent selects" into an internal admin roadmap as a small, predictable line item rather than an open-ended custom-UI epic.
• Build vs. buy for internal tooling. Scope is deliberately narrow: standard Eloquent belongsTo chains only. For that 90% case, integration is hours (declare parent, declare dependent, clear caches) versus days of custom Nova field work plus perpetual maintenance. Default to buy unless the org already owns an in-house Nova field library where this belongs.
• Roadmap sequencing. Because the front-end effort disappears, dependent-field requirements can be pulled forward into the current iteration instead of being parked as "custom UI work." Conversely, it should not be used to justify pulling forward requests for BelongsToMany, MorphTo, or non-Eloquent option sources — those remain custom scope.
• Release 2.0.1 is a reliability upgrade, not a capability change. It only fixes how the field's Index/Detail/Form components are registered. Treat it as the minimum acceptable version (2.0.0 renders blank index/detail columns and throws Failed to resolve component), not as a feature milestone. Do not let it anchor a release note or a stakeholder demo narrative.
• Risk posture and ownership. Low stars, zero dependents, a thin contributor base, and a last release of Feb 2023 mean Nova major upgrades may outpace maintenance. The right decision is to confine it to non-customer-facing admin surfaces, pin the constraint, name an internal owner, and keep a fork-or-replace fallback costed. The code surface is small enough that forking is realistically an afternoon, not a quarter — that's what makes the risk acceptable.
• Total cost of ownership. Budget recurring effort, not just integration: re-validate on every Nova major, keep asset/cache-clearing in the deploy runbook, and add a smoke check that the form renders without console errors. This is the honest number to put against "buy."
• Data integrity is a separate decision. The field restricts what a user can pick; it does not enforce it. Every cascade must ship with a server-side Rule::exists(...)->where(parent_fk, ...) or equivalent. A PM who funds the dropdown without funding the validation rule has funded a UX nicety, not a control.
• Acceptance criteria that actually gate release. Create form works, update form pre-populates the child from the persisted parent (this is the real test — create-only success is a false pass), multi-level chains clear/reload correctly, and fields inside action modals behave (parent must be in the same modal field set). HTTP tests won't catch the reload behavior; plan manual QA or Dusk explicitly.

When to Consider This Package

Consider adoption when:

• You're on Laravel Nova 4/5 and need dependent belongsTo selects in resource forms — this is precisely the problem it solves.
• Your needs are standard: a parent field drives child options through Eloquent relationships, with no complex multi-tenant scoping, bespoke search endpoints, or unusual relationship types.
• The surface is internal admin/back-office, where a pinned, reversible third-party dependency is an acceptable trade.
• You can pin ^2.0.1, verify compatibility against your Nova/Laravel/PHP matrix, and absorb re-validation on each Nova major upgrade.
• Your team can own the operational tail: cache clearing, Octane/FrankenPHP restarts, hard refreshes after deploys, and a deploy smoke test.
• You have someone who will skim the README and the field class before copying — the public API is essentially one make() plus one dependency method, and the dependency argument is the field attribute key, not the foreign-key column. That minute prevents a silently empty dropdown.

Look elsewhere — or build in-house — when:

• You need dependent fields over BelongsToMany, MorphTo, or non-Eloquent option sources. Don't bend the package; scope it as custom work.
• The cascade sits in front of a business-critical or customer-facing workflow with an SLA. No vendor SLA, no recent releases, and no fallback path is a bad combination there.
• You need heavy multi-tenant scoping, custom search backends, or option lists sourced from APIs.
• Your org already maintains a Nova field library — extend that instead, so ownership and upgrade testing stay in one place.
• Child tables are very large and you can't commit to ->searchable() plus an indexed foreign key; a huge option list is a bad dropdown regardless of package.
• You need guaranteed forward-compatibility with future Nova majors on a timeline you don't control.

How to Pitch It (Stakeholders)

One-liner for executives: This is a small, free, MIT-licensed add-on that gives our Nova admin forms proper cascading dropdowns — pick a country, the state list narrows to that country — without custom front-end development. It's an admin-only convenience, not a customer-facing system, and it carries no licensing cost.

For engineering leadership: The package extends Nova's native BelongsTo field with a dependency method, so it's declarative configuration rather than a bespoke Vue component we'd own forever. Integration is measured in hours; the ongoing cost is pinning the version, re-validating on Nova major upgrades, and keeping asset-clearing in the deploy runbook. The codebase is small enough that forking is an afternoon if maintenance lags — that's our break-glass option, and it's what makes the dependency risk manageable.

What we're explicitly not buying: It doesn't enforce data integrity — we still write the paired validation rule — and it doesn't cover many-to-many, polymorphic, or API-sourced option lists. Anything beyond a standard Eloquent belongsTo chain stays on the custom-work backlog.

What I need from the team to say yes:

1. Target ^2.0.1 and verify the installed constraint — 2.0.0 has a component-registration defect.
2. Treat update forms as the acceptance test, not create forms.
3. Ship a matching server-side validation rule with every cascade.
4. Name an internal owner and add "re-validate dependent selects" to the Nova upgrade checklist.
5. Add a post-deploy smoke check: the form renders, the cascade works, no console errors.

Risk statement, stated plainly: small community package, last release Feb 2023, no vendor support. Acceptable for internal admin surfaces with a named owner and a documented fallback; not acceptable as a load-bearing dependency in a customer-facing or SLA-bound workflow.