Laravel Nova Field Dynamic Select Laravel Package

Product Decisions This Supports

• Admin/back-office form UX: enables cascading or dependent dropdowns (country → region → city, category → subcategory, client → project) without custom front-end work, directly improving data-entry accuracy and reducing invalid combinations in operational tooling.
• Build vs. buy for internal admin panels: a thin, purpose-built Nova field is usually cheaper than a bespoke Vue component + API endpoint. This release's fix confirms the package is actively maintained through real usage, not just initial publication.
• Roadmap sequencing for admin/ops features: teams can commit to dependent-field workflows (multi-level filters, conditional option sets) in the current cycle rather than scheduling platform work; the 1.10.0 update-form fix removes a known blocker for "edit existing record" flows, which is where most admin value actually sits.
• Theming/branding decisions: configurable colors let the field match an existing admin theme, lowering the friction of adopting a third-party field into a branded back office. Low strategic value, but removes a common design-review objection.
• Toolchain hygiene: the Laravel Mix 6 bump signals the package tracks current Laravel/Nova front-end tooling — a relevant input when deciding whether to depend on it across multiple Nova upgrades.

When to Consider This Package

Adopt when:

• You are on Laravel Nova and need dependent select options driven by another field's value, where Nova's native capabilities (e.g. the DependsOn container / dependsOn on relationship fields) don't cleanly cover the interaction.
• The dependency chain is shallow (one or two levels) and options come from Eloquent resources you already have.
• You want compiled, drop-in assets rather than maintaining a custom Nova field with its own build pipeline.
• Your admin panel is internal and non-critical-path, so a small community dependency is an acceptable risk profile.
• You need the update/resource-scoped behavior — the headline fix in 1.10.0 makes edit forms resolve fields from the specific resource rather than a generic empty one; if your workflows are edit-heavy, this release is the one to adopt.

Look elsewhere when:

• You are not on Nova, or you're evaluating Jumpstart/other admin stacks — this package is a Nova field and offers nothing portable.
• You need deeply nested or remotely-sourced cascades (async search, pagination, thousands of options) — this is a field-level convenience, not a search/dependency engine.
• You require vendor support, SLAs, or a security review trail. This is a single-maintainer community package; treat it as a "convenience dependency" and budget for the possibility of forking it.
• Your team would rather own the component: for anything central to revenue-generating admin flows, an in-house Nova field is a reasonable build, and the ~200-line scope here makes that tractable.

How to Pitch It (Stakeholders)

For executives: This is a small, free add-on for Laravel Nova, the internal admin tool our team already uses. The new version (1.10.0) fixes a real defect on edit screens — dependent dropdowns now load the correct options for the record being edited instead of a blank default — and adds configurable colors so the field can match our branding. It's a low-cost way to make our internal tools faster and less error-prone without committing engineering time to building custom components. Risk is low but non-zero: it's maintained by a single developer, so we should treat it as replaceable rather than foundational.

For engineering: Minor version bump, no declared breaking changes, no deprecations. Two substantive changes: (1) on update, resource fields are sourced from the specific resource rather than an empty generic instance — this is a behavior fix worth verifying against any existing dependent-select usage in edit forms; (2) custom colors are now configurable. Laravel Mix 6 is a build-tooling upgrade that, for consumers using published compiled assets, should be transparent — confirm asset publishing/caching if we compile from source. Upgrade is low-risk and can ride a normal dependency bump; add a quick manual check of one edit screen per dependent field. No new runtime dependencies of note, no migration required.