Nova Belongs To Dependency Laravel Package

Product Decisions This Supports

• Admin UX scope for internal tooling: Enables dependent dropdown behavior (e.g., Country → State → City, Category → Subcategory, Team → Member) so operators don't see stale or invalid options; this informs whether "guided data entry" is a must-have in our admin panel.
• Build vs. buy for Laravel Nova fields: A concrete data point in the "can we assemble this from community fields, or do we need custom internal components?" decision — particularly for the BelongsTo field type, which Nova's native dependency support handles imperfectly for option filtering.
• Admin stack selection: Signals that the team is invested in Nova (a paid, Laravel-licensed product). If dependent-field UX is a recurring need, this fuels the roadmap conversation "stay on Nova vs. move to Filament/custom admin," since a one-off package here hints at a broader pattern of Nova customization work.
• Use cases it unlocks: Hierarchical selects in CRM/ops dashboards, tenant-scoped pickers, product taxonomy, status-driven record assignment — all low-risk, internal-facing features where admin entry error has real operational cost.
• Not a customer-facing roadmap item: This is infrastructure for internal tooling; it should be evaluated against internal-admin velocity, not end-user product features.

When to Consider This Package

Consider it when:

• The team is already on Laravel Nova and on a Nova version this package actually supports (verify before committing — Nova's dependency API has shifted across majors).
• The need is narrow: one or two fields need to react to a sibling BelongsTo, Text, or Status field's value.
• It is used as a reference implementation or forked baseline, not as a maintained third-party dependency — it is MIT-licensed and archived, so the code is available but support is not.
• Time-to-value matters more than long-term support: a small internal admin screen, a spike, or an MVP.

Look elsewhere (or build in-house) when:

• The feature is core to a production admin surface with an SLA; an archived 10-star package is a maintenance liability.
• The team is on a newer Nova version where built-in dependsOn() or maintained alternatives (e.g., Nova dependency containers) already cover the need.
• The team is not on Nova, or is evaluating Filament/custom admin — the pattern is trivial enough to reimplement natively.
• Multiple fields and complex chains are needed; single-field dependency packages tend to buckle at scale, and a bespoke internal field is cheaper than fighting one.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed utility for our Laravel Nova admin panel that makes dependent dropdowns behave correctly — e.g., filtering cities by the selected state. It removes a common source of operator data-entry errors. Cost of adoption is effectively zero (open source, no vendor), and the risk is low because it lives only in internal admin tooling, not customer-facing systems. The caveat: the project is archived and has ~10 GitHub stars, so we cannot rely on upstream for fixes. Recommendation: treat it as a reference we fork and own internally, not a dependency we adopt — engineering effort is measured in hours, and it eliminates a future "why is our admin panel broken?" conversation.

To engineering: Adopt the pattern, not the package. The code is a compact Nova BelongsTo extension; forking (or reimplementing against Nova's current dependsOn API) gives us a maintained internal component, avoids version-drift surprises, and lets us extend it to status-driven and text-driven dependencies cleanly. Estimate: ~1–2 days to fork, harden, and add tests; ongoing cost near zero.