Nova Autofill Laravel Package

Product Decisions This Supports

• Admin/internal tooling roadmap: Enables cascading / dependent field behaviour (e.g. Country → City, Client → Project) inside Laravel Nova resources without commissioning custom Vue components. This is a recurring "nice to have" that otherwise sits in the backlog behind customer-facing work.
• Build vs buy: Shifts the decision from "do we build a bespoke Nova field dependency layer?" to "do we adopt a small MIT-licensed package?" For most teams the build option is 3–5 days of Nova/Vue work plus ongoing maintenance against Nova upgrades; this package collapses that to a composer require.
• Scope control on internal CRUD screens: Dependent dropdowns are a common source of data-integrity bugs (stale options, mismatched IDs). Standardising on a package gives consistent behaviour across resources rather than each developer hand-rolling a solution.
• Feature gating on Nova as a platform bet: Adopting this is a soft commitment to Nova as the admin layer. Worth surfacing explicitly if there is any appetite for a Filament/Inertia-based admin in the future.
• Upgrade readiness (v1.1.2): The Laravel 9 support in this release helps clear a framework-upgrade dependency, but it is a patch bump with no stated Nova 4 compatibility. Do not treat it as evidence the package is Nova 4-ready — verify against your Nova major version before folding it into an upgrade plan.

When to Consider This Package

Consider it when all of the following hold:

• You are on Laravel Nova and intend to stay there for the next 12+ months.
• You have two or more resources needing dependent/cascading field behaviour; a single one-off case is not worth a dependency.
• Your team has no appetite to own a custom Nova field (Vue + Nova's tooling) across major Nova releases.
• The dependency chain is small and auditable — check composer show chinleung/nova-autofill for transitive weight before committing.

Look elsewhere, or build in-house, when:

• You are not on Nova. This package has no value outside it; Filament and plain Inertia have native or first-party dependent-select patterns.
• You need rich reactive forms — conditional visibility, multi-step wizards, debounced server-side search, complex validation across dependent fields. Scope this as a narrow autofill/option-loading helper, not a form engine.
• Maintenance risk is unacceptable. This is a single-maintainer package with an infrequent release cadence (v1.1.1 → v1.1.2 with a single commit). If your org requires active security response SLAs on dependencies, that is a real gap. Mitigate by wrapping it behind your own field classes so it is swappable.
• Nova version compatibility is unconfirmed. This release adds Laravel 9 support only; it says nothing about Nova 4. Confirm against your Nova major before adoption, and pin the version.

How to Pitch It (Stakeholders)

For executives: We can deliver dependent dropdown behaviour across our admin panel in days rather than weeks, using a small open-source package instead of custom front-end work. It is MIT-licensed, free, and this release keeps it compatible with our Laravel 9 upgrade path. The main caveat is that it is maintained by a single developer, so we will pin the version and keep our usage thin enough to replace if needed. Net effect: faster internal-tooling delivery at near-zero cost, with a known and bounded maintenance risk.

For engineering: chinleung/nova-autofill handles the "field B's options depend on field A" pattern in Nova resources without you writing a custom field. v1.1.2 is a low-risk patch adding Laravel 9 support — no breaking changes, safe to bump. Two asks before we adopt: (1) verify Nova major-version compatibility, since the changelog only mentions Laravel 9; (2) wrap it in our own field subclasses so the package stays an implementation detail. Pin the version in composer.json and treat upgrades as deliberate, tested events rather than composer update side effects.