Nova Child Select Laravel Package

Technical Evaluation

Architecture fit. The package is a Laravel Nova custom field: a Composer-installable package that registers a Vue field component and exposes a fluent PHP API (ChildSelect::make('...')) chained alongside Nova's native field methods. Architecturally this is the canonical Nova extension pattern — no migrations, no domain services, no middleware. It is a thin presentation-layer dependency whose only real contract is the Nova field lifecycle (resolve, fill, rules, jsonSerialize) plus an asset bundle. That means it slots into any Nova resource file without touching application code, but it also means it carries zero business logic — dependent-option filtering, parent/child integrity, and validation remain the application's responsibility.

Integration feasibility. Feasible but conditional on the Nova major version. The repository is archived, which is the dominant signal here: 20 stars and an overall score of ~1.49 indicate a low-adoption, unmaintained artifact. Nova 4 and 5 moved to Vue 3 and Inertia, while packages of this vintage typically target Vue 2 / Nova 2–3. Before any commitment, confirm the composer.json constraint against the licensed Nova version in use. Composer will usually refuse the install outright on a Nova 4+ app — that's a clean failure, but it also means the package is likely unusable as-is on a current stack.

Technical risk.

• Abandonment. Archived upstream = no security patches, no Nova compatibility fixes, no PHP 8.x/Laravel 11+ tuning. The team inherits full ownership on day one.
• Client-side filtering is not a security boundary. A dependent dropdown hides options; it does not prevent a crafted request from submitting a child value belonging to a different parent. Server-side Rule::exists scoped to the parent is mandatory regardless of the package.
• Option payload shape. Inline-embedded option maps scale poorly; API-driven option loading introduces request waterfalls on every parent change. Which mode this package uses is a first-order question.
• No visible test suite or CI, typical of a 20-star Nova field, so behavior under edge cases (null parent, re-hydration on edit forms, dependsOn chains longer than two levels) is unverified.

Key questions.

1. Which Nova major versions are supported, and is the Vue component Vue 2 or Vue 3?
2. Are child options serialized inline with the field payload or fetched on parent change — and what's the query pattern per keystroke?
3. Does it support chains deeper than parent→child, and searchable/relatable selects?
4. How does it interact with Nova's native BelongsTo::dependsOn(), which covers a meaningful subset of the same use case?
5. What is the license, and is the source permissive enough to fork into a private namespace?

Integration Approach

Stack fit. Only viable on a Laravel + Nova stack where the licensed Nova version matches the package's constraint. If the app runs Nova 4/5, treat this repository as a reference implementation, not a dependency — read the component, port the pattern, ship it as an internal field. If the app is pinned to Nova 3, it's installable today but on a stack you should already be planning to leave.

Migration path. Two credible routes:

1. Fork-and-own. composer require from a VCS path or fork into a private package registry, pin the commit, and accept maintenance. Appropriate only if the team already has Vue/Nova field experience and the feature is load-bearing.
2. Build internally or use core. Nova's built-in dependsOn() on relationship fields already handles the common cascading case. For everything else, a bespoke ChildSelect field is on the order of a few hundred lines of Vue plus a small PHP field class — cheaper to own than an abandoned dependency, and it removes the version-matrix risk entirely.

Compatibility. Verify the full matrix before scoping: PHP version, Laravel version, Nova version, Node/build toolchain used for the published assets. Since assets are typically committed to the package, a mismatch between the shipped bundle and the app's Nova asset pipeline surfaces as a broken or unstyled field at runtime, not at install time — plan a smoke test in staging.

Sequencing.

1. Spike (1–2 days): confirm Nova version compatibility; render the field in a throwaway resource; measure the option-loading behavior with a realistic option count (e.g., 5k children).
2. Decision gate: adopt-and-fork vs. build internal vs. use Nova core dependsOn(). Default to the cheapest option that removes the archived dependency.
3. Server-side guardrails: add scoped validation rules and, if needed, a model-level invariant that child belongs to parent — independent of the UI choice.
4. Rollout: staging smoke test on create and edit forms, then production behind the resource-level change.

Operational Impact

Maintenance. Effectively 100% internal from adoption. There is no upstream to receive fixes from, so budget recurring time for Nova upgrades — every Nova major release is a potential breaking change to the field component, and this package will not track it. That cost is small per upgrade but unbounded in aggregate and invisible until the upgrade happens.

Support. Community-only, and the community is 20 stars deep. No issue triage, no documented roadmap, no maintainer response path. Internal engineers become the sole escalation tier, including for questions the original author would have answered in an afternoon.

Scaling. Two pressure points. Payload size: inline option maps are serialized into the Nova field response, inflating index and detail payloads as child cardinality grows. Request volume: API-driven children multiply per-form requests on every parent change, which is fine at 10 concurrent editors and painful at 100. Neither is disqualifying, but both need a number before launch, not after.

Failure modes.

• Silent empty child select — parent value resolves to no option set (ID type mismatch, string vs. integer keys, or an unresolved API call). No error, just a blank field users can't fill.
• Stale options on edit — re-hydration order between parent and child leaves the child showing options for the wrong parent, letting a user overwrite a valid relationship with an invalid one.
• Validation divergence — client filters correctly, server accepts anything; the classic dependent-dropdown integrity hole.
• Upgrade breakage — Nova/PHP bump changes the field registration or Vue API; field disappears or throws at render, discovered in production if staging lacks a Nova smoke test.
• Asset drift — published assets not refreshed on deploy, producing version skew between PHP class and Vue bundle.

Ramp-up. For a developer who has authored a Nova custom field before: a few hours to read the source and be productive. For a team without Vue/Nova field experience: this is a poor first exposure, because they'd be learning the extension pattern and reverse-engineering an unmaintained implementation with no tests or docs to lean on. Factor that into the build-vs-fork decision — the internal build is often the faster ramp, since you write it against Nova's documented field API rather than reading someone else's.

Recommendation. Do not adopt as a standing dependency. Use it as a reference implementation, or fork it into a pinned private package only if the Nova version matches cleanly and the feature is genuinely load-bearing. In parallel — and regardless of the UI path chosen — enforce parent/child integrity server-side, since that is the only part of this problem the package definitively does not solve.