Product Decisions This Supports
- Feature scoping for dependent relationship inputs. This package addresses a very narrow but real admin UX gap: a
BelongsTo select whose option list is filtered by another field (Country → State, Category → Subcategory, Client → Project, Tenant → Team). Use it to size whether cascading selects are worth building at all, or whether a simpler free-text/ID field is acceptable for v1.
- Build vs. buy vs. fork decision. With 2 stars, 0 dependents, and a score of ~1.05, this is not a community-vetted dependency — it is a small, single-maintainer snippet. The decision it actually informs is "vendor and own ~1 field class" versus "adopt a dependency" versus "wait for native Nova support."
- Roadmap prioritization for back-office/admin tooling. If your operators regularly mis-select records because selects are unfiltered (wrong state for a country, wrong project for a client), this is a cheap correctness fix with a measurable error-rate/redo-rate impact — often a better ROI than customer-facing polish.
- Data integrity and validation strategy. Dependent selects reduce invalid foreign-key combinations at the point of entry, which shifts work from server-side validation rules and support tickets to the form layer. Useful input when deciding where to invest in validation.
- Platform-version gating. The existence of this package is a signal about Nova's historical gap in this area; it feeds the decision of whether to upgrade Nova (native dependent-field support) or stay on an older major version and patch around it.
When to Consider This Package
Consider it when:
- You are on an older Nova major (1.x–3.x) where
BelongsTo fields lack clean dependent-select support, and the admin panel is internal-only, low-blast-radius tooling.
- The dependency graph is simple and one-level deep (one parent field filters one child select).
- Your team is comfortable vendoring/forking the field class into your own codebase rather than tracking it as a Composer dependency — MIT license makes this straightforward.
- You need something working this sprint and the alternative is a custom Vue field component plus backend option-resolution logic.
- You accept that you will own tests, maintenance, and security review for the copied code.
Look elsewhere when:
- You are on Nova 4+, where dependent-field behavior is largely covered natively — verify the built-in
dependsOn support against your exact scenario first; writing a custom field may be unnecessary.
- You need multi-level cascades (3+ linked selects), server-side search/pagination on large option sets, or async-loaded options — the package's small surface likely won't cover it.
- Your org requires maintained dependencies with release cadence, CI, security advisories, or a support path — 0 dependents and 2 stars means no external validation and no bus factor.
- Multiple teams will depend on the behavior; a shared internal field package with tests and documentation is a better long-term home than a third-party micro-package.
- You need confidence in compatibility with future Nova/PHP versions, or you're on a PHP/Laravel version the package predates.
Recommendation: Treat this as reference implementation, not a dependency. Budget roughly a day to copy the field class in-house, add tests, and document it — that converts an unmaintained 2-star package into an owned asset with no supply-chain exposure.
How to Pitch It (Stakeholders)
To executives: This is a small, low-cost improvement to our internal admin experience — it makes record-selection forms filter themselves, so operators can't pick a state that doesn't belong to the selected country. The direct benefit is fewer data-entry errors and fewer cleanups. The package itself is a tiny open-source component with essentially no adoption (2 stars, 0 known dependents), so we should not treat it as a vendor relationship. Instead we'd copy the approach into our own codebase under its permissive MIT license and own it — roughly one engineer-day, no licensing cost, no recurring dependency risk.
To engineering: Narrow scope — a Laravel Nova BelongsTo field that resolves its options from a sibling field's value. MIT-licensed, small code surface, so the pragmatic path is to vendor the class, add tests around option resolution and authorization, and own it. Before doing so, confirm whether our Nova version already supports dependent fields natively; if it does, skip the package entirely. If we adopt, we accept responsibility for compatibility with future Nova/PHP upgrades and for any security review, since there's no upstream maintenance signal to rely on.