Select Or Custom Laravel Package

Product Decisions This Supports

• Constrained taxonomy vs. free text. This field is the "both" answer to a recurring product decision: force users into our categories, or let the long tail through and clean it up later. A select with a custom escape hatch means you ship a controlled vocabulary without blocking the user whose value doesn't exist yet.
• Deferring the taxonomy CRUD resource. If admins are the primary writers, letting them add a value inline removes a whole secondary Nova resource (Categories, Vendors, Sources) from v1. That's a roadmap acceleration decision — ship the feature, build the management screen when the list actually grows.
• Data model shape. Single string column instead of enum + nullable free-text pair. Cheaper migrations, simpler queries, easier exports. The tradeoff is lost referential integrity and no per-value metadata — a conscious choice, not an accident.
• Build vs. buy for internal tooling. A Nova field like this is ~150 lines of PHP + Vue. The buy cost is near zero if it runs on your Nova version; the build cost is an afternoon. Treat it as a timeboxed evaluation, not an architecture commitment.
• Representative use cases: vendor/supplier entry, lead source, expense category, job title, region with "other," integration mapping config, single-select tag-like fields where the list is small and stable and custom entries are the exception.

When to Consider This Package

Adopt when:

• You're on Laravel Nova and already have a select field users complain about ("my option isn't in the list").
• The option set is small and slow-moving (tens to low hundreds), and custom entries are the exception rather than the norm.
• Admin users are trusted — no approval workflow needed for newly introduced values.
• You're willing to vendor or fork it. With ~10 stars, zero dependents, and a weak maintenance signal, treat it as code you're adopting, not a dependency you're relying on.

Look elsewhere or build it yourself when:

• You're not on Nova. This is Nova-only and has no value outside that ecosystem.
• Nova version support is unclear. Check the field's Nova constraint and last commit before anything else — an unmaintained field breaks on major upgrades.
• You need per-value metadata, ordering, translations, or permissions. That's a real taxonomy resource, not a field.
• Custom values need normalization or dedup ("Acme" / "acme" / "Acme Inc"). That's validation and an observer, not a field.
• You need multi-select, regex/domain validation on the custom branch, or dependent-field behavior.

How to Pitch It (Stakeholders)

Executives: "One form field instead of two admin screens. It unblocks an onboarding flow and lets us delay the taxonomy management screen instead of building it now — roughly a day of build saved, no user-visible downside, and it's trivially removable."

Engineering: "A Nova field that renders a select plus a free-text escape hatch and stores a single string. Presentation layer only, so blast radius is low. Caveat: it's a 10-star package with no dependents and a weak health score — pin it and vendor it, or plan to reimplement in an afternoon. Do not let it become load-bearing."

Recommendation: Adopt as a one-day evaluation spike. If it doesn't integrate cleanly with your Nova version, write the field in-house. Never take a dependency you can't drop in an afternoon.