Nova Child Select Laravel Package

Product Decisions This Supports

• Build vs. buy (really: buy vs. build vs. use-native) for dependent dropdowns. This package exists to solve a narrow, recurring admin-panel requirement: a "child" select whose options are filtered by a "parent" select's value (country → state → city, category → subcategory, client → project). The PM decision it informs is whether cascading selects are worth custom front-end work or should be handled by what Laravel Nova already ships.
• Feature scoping for internal tooling. Cascading selects are rarely a differentiator; they are data-quality infrastructure. They reduce free-text entry errors, invalid state/province combinations, and mis-assigned records — which shows up as fewer support tickets and cleaner reporting, not as a headline feature.
• Roadmap prioritization for admin UX debt. If operators are currently picking from a flat 500-item dropdown or typing values by hand, this is a cheap, contained improvement to an internal workflow. If the admin is used by ten people once a month, it is not worth a sprint.
• Platform/compatibility decisions. The package is archived, has ~20 stars, and no upstream maintainer. That makes it a reference implementation input to a build-vs-buy call, not a dependency you plan a roadmap around. The real decision is usually "upgrade Nova and use native field dependencies" versus "fork this pattern into our own field class."
• Typical use cases worth evaluating: geography hierarchies, product taxonomy (department → category → subcategory), org structures (region → office → team), and any parent/child pair where the child set is small enough to ship to the browser at page load.

When to Consider This Package

Consider it only when all of the following hold:

• You are on an older Nova major version (Nova 2/3 era) where native dependsOn-style reactive option filtering is unavailable or insufficient for your case.
• The dependent dataset is small and static enough to be loaded eagerly — no need for AJAX-backed, searchable, paginated child options.
• The consumer is an internal admin panel with a small, known user base, so a bug in a dropdown is an annoyance, not a revenue event.
• You are prepared to vendor or fork it: pin the source into your repo, add it to your own test suite, and treat it as first-party code you now own.

Look elsewhere (or build in-house) when:

• You are on Nova 4+, where native field dependency and reactive option handling cover most cascading-select needs — adopting a third-party field there adds risk for no capability gain.
• You need active maintenance, security patching, or PHP/Nova version support guarantees. An archived repo gives you none of that; a future Nova upgrade can silently break it.
• Your child option sets are large or dynamic (thousands of rows, permission-filtered, or tenant-scoped). That is an AJAX/searchable-select problem, and a simple child-select field will not carry it.
• You operate under compliance or dependency-review gates that require a maintained upstream, a license check, and a documented CVE response path.
• The interaction is customer-facing. Archived UI code in a revenue path is an unacceptable risk concentration.

How to Pitch It (Stakeholders)

To executives: This is a small, low-cost improvement to internal admin data entry — dependent dropdowns that stop operators from saving invalid combinations, which improves reporting accuracy and reduces cleanup work. However, the package itself is archived and has minimal adoption, so the recommendation is not to adopt it as a dependency. Instead, treat it as a proven pattern: either use the cascading-select capability already present in our Nova version, or budget a few days of engineering to implement and own roughly 150 lines of field code. Either path delivers the workflow benefit without inheriting an unmaintained third-party risk.

To engineering: The package is a Nova field that filters a child select's options from a parent select's value. It is unmaintained and version-pinned to older Nova. Evaluate in this order: (1) does our Nova version's native field dependency cover the requirement? (2) if not, fork the pattern into an in-house field with tests and an owner; (3) only vendor the archived package if the timeline is tight and we accept it as disposable code with a documented exit plan. Do not add it to composer.json as an unpinned dependency.