Nova Select Plus Laravel Package

Product Decisions This Supports

• Unblocking large-dataset admin UX without custom front-end work. Nova's native Select is fine for a dozen options and unusable at a thousand. This field gives searchable, AJAX-backed, paginated selection, which is the difference between "our ops team can assign accounts in the admin panel" and "ops files a ticket for an engineer to do it in tinker."
• Build vs. buy on internal tooling. A hand-rolled Nova field with async search, pagination, dependency chaining, and label/value resolution is roughly 2–5 engineer-days plus permanent Vue/Nova-upgrade maintenance. This is MIT-licensed and free, so the buy case is strong if you accept the fork-and-maintain cost — see the caveat below.
• Roadmap sequencing for admin/back-office features. Because integration cost is low (a composer require plus a field declaration), features that were previously gated on "we need a better select component first" — multi-tenant assignment flows, cascading region/territory pickers, tag-style multi-select on thousands of records — can be pulled forward into the current cycle instead of deferred.
• Concrete use cases worth scoping: assigning an owner/CSM/account from a large user table; linking an order to one of 50k SKUs; cascading selects where a child field's options depend on a parent (country → region, plan → add-ons); filter panels on admin indexes. Note that cascading selects specifically were buggy on the form side until v2.0.2 — if dependency chaining is your primary motivation, scope it against 2.0.2 or later and validate it in a staging form before committing the roadmap slot.
• A cheap way to evaluate the "searchable select" pattern before investing. Ship it internally in a week, watch whether ops actually uses search vs. scrolling, and only then decide whether the pattern deserves a bespoke component or belongs in your product-facing UI.

The caveat that shapes the decision: the package was dormant from April 2023 until v2.0.2, which lands ~2.5 years later. That release is a positive signal — the maintainer is still merging PRs, accepted an outside contributor, and fixed a real defect in the dependency-chaining feature — but it is a single patch release, not a reversal of the underlying profile: ~95 stars, effectively zero downstream dependents, essentially one person with commit rights. Treat the project as lightly maintained rather than abandoned, which changes the risk from "dead on arrival" to "alive but thin." It is a fine choice for internal admin tooling; it is not a dependency you want in a customer-facing or long-lived critical path. Budget for a fork (vendored or a private mirror) as a day-one line item, not a later surprise — the fork cost is unchanged, but the odds you'll be forking into a moving target rather than a frozen one just went up slightly.

When to Consider This Package

Consider it when all of the following hold:

• You are already on Laravel Nova 3 or 4 — it's an add-on to a paid admin panel, so it only makes sense inside an existing Nova investment.
• You need selection over option sets too large to render inline (hundreds to tens of thousands of records), or you need dependency-driven option lists — and if it's the latter, you're pinning ≥ v2.0.2, which is where the DependsOn integration on Form.vue was fixed.
• The consumer is internal — support, ops, finance, sales engineering.
• You have in-house PHP/Vue capacity to read and patch the field when Nova ships a breaking change, and you're comfortable pinning a version or forking.

Look elsewhere — or defer — when:

• You are on Nova 5 or planning to upgrade. Verify compatibility first; v2.0.2 is a patch on the 2.0 line and does not advertise Nova 5 support, so "does it work on 5" remains an unknown until proven. Don't read this release as a compatibility answer.
• The field sits in a customer-facing or revenue-critical path.
• Nova's built-in BelongsTo with searchable() already covers your case — for simple "pick one related model" fields it usually does, and native beats third-party.
• You are still choosing an admin stack. If Filament or a custom admin is on the table, don't pick Nova plus a thinly-maintained third-party field to get searchable selects; that's a workaround, not a strategy.
• The team has no appetite for maintaining a thinly-maintained dependency — in which case the 2–5 day build is the honest comparison, and it may still win. A maintenance pulse every ~2.5 years doesn't change that math much.

How to Pitch It (Stakeholders)

For executives: We can give our operations team a working search-and-assign interface in the admin panel for roughly one engineer-day, at zero license cost (MIT), instead of a multi-day custom build. It's an internal-tooling accelerator, not a product differentiator. The trade-off is that the package is small — around 95 stars, one principal maintainer — and it just shipped its first release since 2023, which tells us it's alive but thinly resourced. We should treat it as code we adopt and own: I'm asking for one day of fork-and-maintain budget alongside the integration, which is still well under the cost of building it ourselves. The new release is a small bug-fix and styling patch, so it doesn't change our plan — it slightly improves our confidence in the upstream.

For engineering: ziffmedia/nova-select-plus is a Nova field that swaps the stock Select for an async, searchable, paginated picker with dependency chaining. Integration is composer require plus a field definition; MIT license, no lock-in. v2.0.2 just landed: form-field style improvements (#56) and a fix for DependsOn on the Form.vue side (#57) — the latter matters directly if we're using it for cascading pickers, so pin at least this version. It's a patch bump on the 2.0 line, no breaking changes or deprecations, so no migration work. Two things I still want your read on: (1) Nova 5 compatibility is unverified and this release doesn't address it — confirm before we commit, and (2) I'm treating upstream as lightly maintained, not dormant — one patch release after a 2.5-year gap, so I'd still pin and fork into our own namespace from the start rather than consume directly. If you'd rather just build the field, tell me the real estimate and I'll take that comparison to the roadmap review.