Select Or Custom Laravel Package

Technical Evaluation

Architecture fit. This is not a general-purpose Laravel package — it is a Laravel Nova field. Its entire surface area is a PHP Field subclass plus a compiled Vue component that Nova loads into its SPA. That means the addressable footprint is limited to applications that (a) run Laravel, (b) hold a paid Nova license, and (c) have an admin resource where a "pick from list or type your own" input is the correct UX. Outside Nova it is inert; inside Nova it is a leaf-node UI dependency with no service-provider magic, no config, and no runtime hooks. Architecturally that is the safest possible shape for a third-party package — it cannot interfere with request lifecycle, queues, or the container — but it also means the value is entirely concentrated in a small piece of front-end behavior we could reproduce in-house in well under a day.

Integration feasibility. Mechanically straightforward: composer require, register the field on a Nova resource, publish assets if required, and define options(). The real friction is version alignment. Nova's front-end moved to Vue 3 with Nova 4, and Nova 5 changed the asset/build toolchain again; a field last released in February 2023 is very likely pinned to a Nova 4-era toolchain. Before committing we need to read the package's composer.json constraints and the compiled component's Nova dependencies, and confirm whether the resolve/fill/displayUsing paths behave correctly across index, detail, and form views.

Technical risk. High, and mostly non-technical in origin. Zero stars, zero dependents, single maintainer, no release in over two years — there is no evidence of production use anywhere, which means we would be the first real integration test. The package name (select-or-custom) and repository name (select-or-text) diverge, which is a small but telling signal of low maintenance discipline and complicates discovery, Packagist verification, and future fork/rename work. There is no visible CI, no security policy, and no dependency-update cadence. Abandonment should be assumed as the base case, not the risk case.

Key questions.

• Which Nova and Laravel versions are declared, and has anyone verified the component compiles/loads under Nova 5?
• Is the value persisted as a single string column, and are null, empty string, and "custom with no text" distinguishable?
• Can the free-text branch be constrained (max length, allowed pattern), or does it silently bypass validation rules attached to the underlying column?
• Is the custom text rendered through Nova's escaping on index/detail, or interpolated?
• Is there filtering/sorting support, or does the field degrade to a plain text column in those contexts?
• What is the license, and does it permit an internal fork?

Integration Approach

Stack fit. Only consider this if the target application is already on Nova and the team has accepted Nova as the admin layer. If the admin surface is Filament, Backpack, or hand-rolled Blade, this package is irrelevant — stop here and treat the requirement as "a select with an 'Other' escape hatch," which is a standard form pattern.

Build-versus-buy. Given the adoption signals, the honest recommendation is to build. A Nova field that renders a <select> plus a conditional <input> and resolves to a single string is a small, well-understood piece of work: one PHP class, one Vue component, one npm run prod. Owning ~150 lines is cheaper over a two-year horizon than owning a dead upstream. If the team wants to move fast, fork the repository rather than depending on it — same code, but the dependency is now internal and reviewable.

Migration path. If already installed elsewhere in the estate, plan the exit at the same time as the entry: fork to an internal namespace, pin the Nova constraint, add a smoke test, and record the fork in the dependency inventory. If this is greenfield, prefer Nova's native Select field combined with a companion text field gated by dependsOn, or a Select whose options are supplemented at runtime — both avoid the third-party dependency entirely and keep the value semantics explicit.

Compatibility and sequencing.

1. Verify composer.json constraints against the project's Laravel and Nova versions; do not install on faith.
2. Stand up a throwaway Nova instance at the target version (not the current one) and exercise create, update, index, detail, sorting, and filtering.
3. Confirm the storage column definition and back-fill/nullability behavior before any schema work.
4. Only then introduce into the real resource, behind a feature branch, with a screenshot-level acceptance check on the "custom" branch.
5. If Nova is scheduled to upgrade within the planning horizon, defer adoption or build in-house — the upgrade will land on this package and there is no upstream to fix it.

Operational Impact

Maintenance. Effectively zero upstream maintenance; assume 100% internal ownership from day one. Budget a recurring line item for "fork survives Nova upgrades," because the Vue asset is the most upgrade-fragile part of any Nova installation. A single maintainer with a two-year release gap is not a support relationship — it is a code snapshot.

Support. No community, no issue triage, no security advisories to subscribe to. Any defect becomes an internal ticket with no upstream escalation path. This is acceptable for a presentation-layer field and unacceptable for anything touching authorization, validation, or persisted business rules.

Scaling. Negligible. The field executes only inside authenticated admin requests and performs no queries, caching, or I/O beyond the form round-trip. It will not be a throughput or capacity consideration at any realistic admin scale. The only scaling concern is organizational: one more bespoke dependency per additional Nova app multiplies the fork-maintenance surface.

Failure modes.

• Upgrade breakage: Nova bump invalidates the compiled asset; the field renders blank or throws in the SPA, with no upstream fix.
• Semantic ambiguity: "custom" selected with empty text collides with a genuinely empty value, producing dirty data that downstream reporting cannot distinguish.
• Validation bypass: free-text entry writes values the column's domain never anticipated, silently poisoning enum-like data.
• Rendering: custom text surfaced on index/detail without consistent escaping — low probability given Vue's defaults, but unverified.
• Discovery/install: repository-name versus package-name mismatch causes the wrong package to be pulled or the install to fail outright.

Ramp-up. A Laravel developer with Nova experience can integrate and validate this in roughly half a day; the fork-creation and upgrade-testing overhead adds another day. The misleading cost is the ongoing ownership, not the initial setup. For a single admin screen the math favors building in-house; for a fleet of Nova apps with a hard deadline it may still be worth the fork, provided that decision is made explicitly rather than by default.