Nova Belongsto Depend Laravel Package

Product Decisions This Supports

• Admin/back-office roadmap, not the customer product. orlyapps/nova-belongsto-depend improves internal Laravel Nova forms so one relationship select filters another — country → state, client → project, category → subcategory, team → member. It is an admin productivity and data-integrity lever. It creates no customer-facing capability, so it should compete for maintenance budget, not roadmap priority.

• Data quality as a measurable outcome. Cascading selects prevent operators from saving invalid parent/child combinations. That means fewer bad records, less manual cleanup, and fewer downstream support tickets. This is the strongest PM argument for adoption — frame it around defect reduction and entry speed, not developer convenience.

• Build vs. buy on a very small decision. The real choice is not "adopt this package vs. do nothing." It is "adopt this unmaintained field vs. reproduce it with Nova's native dependsOn() + relatable() in roughly a hundred lines we own." Because reimplementation cost is low, the package's value is convenience — which caps how much upgrade risk is rational to accept.

• Feature scoping within a single workflow. Adopt it as a contained enhancement to one or two resources, with the option to widen later. Do not let a single lightweight field become an unexamined platform dependency, and do not let it justify deferring a Nova upgrade.

• Risk-and-ownership decision. Last release June 2022 (177 stars, zero dependents, single-maintainer agency package, compiled Vue asset with no build chain). Treat as: high likelihood of breaking on the next Nova major, low severity for a sub-500-line field, cheap to fork (MIT), expensive to adopt passively.

• Explicitly out of scope. Not for customer-facing forms, not for complex multi-step or permission-aware cascades, not where a vendor SLA or active release cadence is required, and irrelevant if the stack is not Laravel Nova.

When to Consider This Package

Consider it when:

• The product already runs Laravel Nova in production for internal operations, and paid Nova Composer credentials are present in every environment (CI, staging, developer laptops).
• Two or more Nova resources need a dependent BelongsTo pair and the team wants to avoid writing yet another custom Nova field.
• The workflow is internal and low-risk — outside the revenue path and under lighter change control.
• Engineering can run a timeboxed spike (0.5–1 day) on a throwaway branch, record the exact Nova version it mounts against, pin both the package version and laravel/nova in composer.lock, and commit a named owner plus a documented fallback.
• Expected return is concrete: faster back-office entry, fewer invalid relationship combinations, measurable reduction in corrected records.

Look elsewhere when:

• The stack is not Nova, or the need surfaces in customer-facing rather than admin forms.
• The team requires active maintenance, recent release cadence, or vendor support — the 2022 release sits at the Nova 3 → 4 (Vue 2 → Vue 3) boundary, and Nova 5 support is unverified.
• The dependency logic is complex, multi-step, permission-aware, or central to a revenue-generating workflow.
• Engineering cannot absorb the compatibility and testing cost, or the current Nova/Laravel/PHP versions are not explicitly supported.
• The native dependsOn() + relatable() spike reaches parity — in that case buy nothing, take the in-house field, and close the ticket.
• You cannot answer whether filtering is a constrained server-side query versus fetch-all-then-filter. The latter is a data-correctness and performance hazard on large lookup tables and is grounds to skip on its own.

How to Pitch It (Stakeholders)

For executives: This is a small, low-cost admin UX improvement, not a strategic platform dependency. It makes internal Nova forms smarter by filtering related dropdowns, which improves data integrity and reduces manual correction. The catch is lifecycle risk: MIT-licensed and cheap to adopt, but last released in 2022, low known adoption, single maintainer, and a compiled frontend asset we cannot patch without a rebuild. Approve it as a tactical, scoped trial with a named owner and a fallback — not a long-term platform commitment. The right ask is a day of engineering and a line on the Nova upgrade checklist, not a procurement cycle.

For engineering: A Laravel Nova field enabling dependent BelongsTo selects. Install is composer require with auto-discovered provider and a vendor route — no migrations, no config, no service boundary; blast radius is confined to Nova admin forms. The work is validation, not integration: run a spike against the Nova version in production today and the one planned twelve months out, exercise create/edit/validation-error/searchable/empty-state, confirm the option lookup is a constrained query, pin versions, and document the fallback (fork under our org, or implement a minimal custom field). If the spike shows any compatibility friction, build the in-house field — the asset bundle is opaque, and forking early is materially cheaper than forking under incident pressure. Watch the failure mode: after an upgrade the field can render with dependent options silently never refreshing, so it warrants an explicit smoke test on the dependent form in the upgrade checklist.

For product: Fund it only where admin speed or data integrity carries operational value you can point at — invalid records avoided, back-office entry time saved. Do not position it as a differentiator, and do not let it gate a Nova upgrade. If the workflow becomes important enough to depend on, budget ownership — a fork with a named maintainer — rather than assuming the package stays current.