Nova Inline Select Laravel Package

Product Decisions This Supports

• Build vs. buy for internal admin UX. Nova is a licensed, already-paid-for dependency in most shops using it. This package is a free, MIT-licensed field extension that substitutes for "commission a custom Nova field" (typically 1–3 engineer-weeks plus permanent maintenance ownership) or "stand up a separate ops console" (a quarter-plus and a new service to operate). Because the change is one field class on one resource, it is a team-level, reversible decision — not a platform bet that needs escalation.
• Roadmap triage on operational throughput. It maps cleanly onto the recurring "cut clicks for support/ops" backlog item without consuming a sprint. The target is narrow and high-frequency: single-scalar edits made directly on a resource index — status transitions, stage advances, priority bumps, owner/category reassignment, disposition codes. That's exactly the pattern where saved seconds compound across hundreds of daily actions and surface in cycle-time and time-to-resolution metrics.
• De-risking the Nova v5 upgrade. Release 3.0.0 exists solely to add Nova v5 support. For teams whose ops workflows depend on inline editing, that converts "upgrade the admin panel" from blocked to schedulable — and reframes this package as a pre-upgrade checklist line item rather than a mid-migration surprise discovered by support staff on a Monday.
• Validating an interaction pattern before investing in it. If the roadmap contemplates queue views, moderation queues, ticket triage, lead pipelines, or fulfilment dashboards, inline editing on the list is the expected interaction. This is the cheapest possible way to put that pattern in front of real operators and measure whether it earns further investment — or whether ops still opens every record, in which case you've learned something valuable for a fraction of a sprint.
• Scoping how much bespoke admin surface you actually need. Useful counterfactual: if inline edits absorb ~80% of the demand for custom admin tooling, that is evidence against a heavier internal-tooling bet, and it belongs in the same conversation as any proposal for a dedicated ops app.
• Marginal-cost capability expansion on a sunk platform. No data-model change, no migration, no new service, no new on-call surface. It stays out of platform-strategy debates because it doesn't touch core product architecture.

When to Consider This Package

Consider it when:

• Laravel Nova is already the admin layer and the license is a sunk cost. Without Nova, this package is inert — that's the first gate, not a detail.
• You're on Nova v5, or actively sequencing that upgrade. Pin explicitly: ^3.0 for Nova 5, ^2.0 for Nova 4. Treat the major bump as a deliberate, separate step, never as an incidental composer update side effect.
• The dominant editing pattern is one scalar field on a resource index — a status transition, a stage advance, a priority bump, an assignment. If most edits need two or three fields together, the value collapses.
• Validation needs are simple (enum or in: rules) and the field doesn't drive cascading UI. A country picker that must repopulate a city list is the wrong shape for a table cell.
• The option set is small — roughly 3–8 values. A 200-item dropdown in a cell is unusable; that's a searchable relationship field or a Nova action with a picker.
• The audience is internal staff — support, ops, fulfilment — where a slightly rough edge is tolerable and the blast radius is contained to a reversible field.
• You want a timeboxed, pilot-shaped experiment, not a platform commitment. Adoption should be one resource, one field, with a documented rollback (delete the field line, composer remove).

Look elsewhere when:

• The field is audit-, money-, or permission-sensitive. Inline edits bypass reason codes, approval steps, and confirmation dialogs. Billing state, refunds, entitlements, and compliance statuses need a deliberate detail-form flow — that's a product requirement, not a tooling gap.
• You need multi-select, dependent/per-row option sets, or custom rendering. There is no service provider, no config file, and no extension surface beyond Nova's own. At this code size, forking under your own namespace (MIT permits it) is a realistic fallback — and that forkability is also the mitigation for the package's thin adoption (93 stars, zero dependents).
• Several people edit the same rows concurrently and a lost update is expensive. Saves are last-write-wins and the index doesn't refresh itself. Either accept it on cheap-to-correct fields, or design a stale-row signal.
• You expect the field's ->rules() to be your safety net. Test empirically before rollout; if invalid values persist from the index, the guard belongs in a model observer or the database.
• You're pre-Nova-5 and not ready to hold two version tracks. Running ^2.0 is fine, but it is a frozen line — plan the migration rather than drifting into it.

How to Pitch It (Stakeholders)

To executives (30 seconds): Our admin panel is where support and ops spend their day, and the single most common action is changing one value — a status, a stage, an owner. Today that costs a page load, an edit form, and a save, every time. This is a free, MIT-licensed field for the Nova admin panel we already pay for that lets staff change those values inline with an instant save. It replaces a custom build we'd otherwise scope at 1–3 engineer-weeks, requires no new service or infrastructure, and rolls back in a single commit. Expected payoff is cycle-time and throughput on operational queues, not new revenue — treat it as internal-tooling efficiency, piloted on one screen and measured before expansion.

To engineering (the important part): This is a drop-in Select replacement — same options(), displayUsing(), and label API — so the work is one field class on one resource, plus a smoke test. The real risks are not the code, they're the edges: the 3.0 line is Nova-5-only (pin the constraint, don't let Composer float you), the index becomes a write surface so per-row authorization and model-level validation matter more than the field's ->rules(), and model observers may double-fire or skip on an inline save and must be tested with a real click per model. Assets are the classic failure mode — a missing compiled dist/js/field.js renders as plain text, and often only in a versioned production build, so re-publish and verify against prod assets after every Nova bump.

What I'm asking for: one engineer, roughly a day, on one low-risk queue resource — plus agreement that we watch three numbers for two weeks (edits per operator per day, time-to-update on the queue, and form-opens for that resource) before deciding whether to widen it. If the numbers don't move, we delete one field line and we're done.

Known trade-offs I'm accepting, on the record: low adoption (93 stars, no dependents) means we rely on forkability rather than community depth as our continuity plan; concurrent edits are last-write-wins; and this stays off anything audit- or money-sensitive by policy, not by accident.