Nova Field Sortable Laravel Package

Product Decisions This Supports

• Self-serve editorial curation vs. an engineering ticket queue. Today every "move X above Y" request — banners, FAQs, categories, nav links, pricing tiers, media galleries, workflow stages — routes through a person who writes code. Drag-to-reorder in the Nova index converts that into an editor capability. The business case is stated in hours saved: count the reorder requests in the 60 days before and after, not the features shipped.
• Roadmap sequencing: is manual sort a v1 requirement or a later one? Curated ordering is a real product surface (merchandising, editorial ranking, prioritization) and it creates persistent state the team must keep consistent forever. Choosing manual sort later is cheap. Removing it after editors depend on it is not. Decide deliberately rather than defaulting.
• Build vs. buy vs. skip, written down. The honest options are: a bespoke Nova action or page (~a sprint), resurrecting this MIT field (~3–6 engineering days including the compatibility port), or changing nothing and keeping the ticket queue. All three are defensible — the decision record should name the choice and the reason.
• Vendor-risk posture as an explicit decision. Last release October 2018, 58 stars, zero Packagist dependents, no security contact, no issue triage. This is not "install a dependency." It is "adopt a few hundred lines of source and own it outright, including every future Nova upgrade." That framing belongs in the decision log whatever the outcome.
• Reference implementation as an accelerator. Even if we never ship it, reading a working Nova field de-risks and sharpens the estimate for our own build. Value can be captured without adoption.
• Ecosystem-health signal for the dependency policy. Zero dependents and no community means no third-party patches and no peers to surface breakage on a Nova upgrade. If we lack a written policy for unmaintained packages, this is the moment to write one — and this package is a clean test case.

When to Consider This Package

Consider it when:

• The admin runs Laravel Nova 1.x–2.x, or the team has explicitly budgeted a compatibility spike and port.
• Models carry a simple single-column order / position / sort_order integer, and the requirement is flat, single-list reordering — not trees.
• A non-technical editor genuinely needs drag-and-drop in the index; up/down arrows or a numeric input won't clear the UX bar.
• The team will vendor the MIT source into the repo at a pinned commit and name an owner. There is no upstream SLA and no security contact.
• Lists are tens to low hundreds of rows, so a write-per-drag isn't a throughput or concurrency problem.
• It's being used as a reference implementation to accelerate a bespoke build rather than as a live dependency.

Look elsewhere when:

• You're on Nova 3/4/5 or upgrading soon — the 2018-era Vue 2 + Laravel Mix assets need rewriting, not installing. On Nova 4/5 you are porting source, not adding a package.
• You need hierarchical or nested ordering (tree menus, multi-level categories); this field sorts one flat list and has no concept of a parent.
• Multiple editors will reorder the same list concurrently — you need your own transactional write path, row locking, and a uniqueness constraint on position.
• Policy mandates maintained dependencies with recent releases and a disclosed security contact.
• The order is derivable from data (name, date, score, priority). Don't introduce manual sort state you then have to keep consistent forever.
• Nova's built-in sorting (->sortable() on index fields, $defaultSort) already satisfies the requirement. Then this initiative dies here — and that's the first thing to check, before any estimate is written.

How to Pitch It (Stakeholders)

Executives. Editors can't change the order of [X] without opening a ticket — roughly [N] requests a month, plus added latency on routine content changes. A small MIT-licensed Nova field adds drag-to-reorder to the admin for about a day of setup, against roughly a sprint to build the same thing ourselves. The catch matters and should be said out loud: it hasn't shipped since 2018 and has essentially no user base, so we'd be adopting the code, not buying support — we own it, including every Nova upgrade. Recommendation: approve a short spike on one low-risk resource, measure the ticket drop, and expand only if the port proves cheap. Kill it if the spike runs past two days, or if Nova's native sorting already covers the need.

Engineering. It's one Nova field — a PHP Field subclass plus a compiled Vue component — that makes index rows draggable and persists position to an order column. Practically: do not composer require from Packagist. Vendor the source at a pinned commit, read the reorder route before trusting it (it is the entire security surface — treat it as an IDOR candidate and put the model's update policy in front of it), and wrap the write in a transaction with row locking. Do not stack it on spatie/eloquent-sortable; both want to own the order column and you'll get double-writes. Assume Nova 4/5 means a day or two porting resources/js/ to Vite — and treat exceeding two days as the signal to write a bespoke field, because the underlying logic is genuinely shallow. Name an owner, pin the commit, and note in the README how our fork diverges; the failure mode after a Nova upgrade is silence — the handle simply doesn't render and nothing errors — so keep a render smoke test as the canary.