Nova Field Sortable Laravel Package

Product Decisions This Supports

• Build vs. buy for admin ordering UX. This package is a small, MIT-licensed drag-and-drop sort field for Laravel Nova (a fork of naxon/nova-field-sortable). It lets you decide whether to spend engineering days building reorder controls for curated content — categories, FAQ entries, media galleries, related-item lists — or drop in a field and move on.
• Roadmap scoping for back-office tooling. If content editors repeatedly ask "can I change the order of these items without a developer?", this is a ~1-day spike to validate demand before committing roadmap capacity to a custom admin feature.
• Prioritizing curation workflows over end-user features. Ordering/ranking is often a silent driver of merchandising, onboarding flows, and navigation quality. Adopting a cheap field lets you test whether manual ordering actually moves a business metric (conversion, engagement) before investing in a full ordering service.
• Feature-level go/no-go for a single surface. Because it's a field, the blast radius is one Nova resource. That makes it a low-risk pilot: prove the workflow internally, then decide whether to productize it (soft-deleted ordering, multi-locale ordering, scheduled ordering) or leave it as an internal tool.
• Deprecation and technical-debt decisions. With 3 stars, 0 dependents, and a last release of 2021-06-11, the real decision it supports is "do we vendor and own this, or avoid the dependency entirely?" — a portfolio-level judgment about how much unmaintained code your admin layer can tolerate.

When to Consider This Package

Consider it when:

• You are already running Laravel Nova (it is useless without a Nova license — that's a separate, paid dependency with its own cost and upgrade cadence).
• You need simple, single-resource ordering persisted to an integer/sort column, edited by trusted internal staff.
• Your team is comfortable vendoring the code into your app (or a private fork) rather than depending on Packagist updates.
• The admin surface is internal-only, so a UI regression is an inconvenience, not a customer-facing incident.
• You are willing to timebox a spike to confirm compatibility with your current Nova/Laravel versions — the 2021 release predates several major Nova and Laravel releases, so verify before planning around it.

Look elsewhere when:

• You don't use Nova, or you're evaluating a move off it — building ordering with plain Blade/Livewire or Filament avoids the Nova license and this fork entirely.
• You need reordering of index rows across a whole resource rather than a relation/field-level sort — sibling packages in this space cover different cases, so confirm which problem you actually have.
• You need maintenance guarantees: security patching, version support, tests, CI, or an SLA. Three stars, zero dependents, and a single-maintainer fork offer none of that.
• Ordering is business-critical (e.g., pricing tiers, regulated content sequencing), where you want owned code, migrations you control, and audit trails.
• You're on a modern PHP/Laravel/Nova stack and can't afford to debug an abandoned dependency during an upgrade window.

How to Pitch It (Stakeholders)

To executives: This is a free, MIT-licensed UI component that could save a few engineering days on admin "reorder these items" requests. The catch is that it's a low-adoption fork last updated in 2021, so I'm not recommending it as a standing dependency — I'm recommending a short, timeboxed evaluation to see whether it solves an existing internal workflow. Worst case we spend a day and learn we should build it ourselves; best case we ship an editor-facing improvement this sprint at near-zero cost.

To engineering: This is a Nova field (fork of naxon/nova-field-sortable, MIT) that adds drag-and-drop ordering backed by a sort column. It's small and readable, so the practical path is to vendor it into our repo, pin it, and treat it as our own code rather than relying on upstream. Before committing, please confirm compatibility with our Nova and Laravel versions, check the migration/pivot expectations, and sanity-check the queries it generates on a table of realistic size. If it needs more than a day of fixes, we fall back to a custom implementation and I'll re-scope.

Recommendation: Adopt as a vendored, internal-only pilot with a named owner and a documented exit path; do not add it as a production dependency for customer-facing surfaces until it has survived one framework upgrade cycle.