Nova Sortable Laravel Package

Product Decisions This Supports

• Roadmap: ship "editor-controlled ordering" without a custom build. Any roadmap item that says "content should appear in the order our team decides, not by created_at" is a fit. This is the cheapest credible path to that outcome on a Nova stack.
• Build vs. buy: buy (and it's free). MIT-licensed, no seat cost, no vendor contract. The build alternative is a custom drag-and-drop Vue component inside Nova plus sort-order column, gap management, and rebalancing logic — realistically 1–2 engineering weeks and ongoing ownership. This package plus Spatie's eloquent-sortable collapses that to roughly half a day to one day per resource (migration, backfill, trait, resource config, QA).
• Use cases to scope, in priority order:
  1. Merchandising / editorial ranking — featured items, homepage rails, category ordering, "top picks" lists that a non-technical operator curates.
  2. Navigation & menu assembly — ordered menu items, ordered links in a footer or resource block.
  3. Workflow priority queues — ordered task/stage lists where humans override the default sort.
  4. Ordered child collections — HasMany detail views (agenda items, gallery images, FAQ entries) and BelongsTo/MorphsTo relationships with pivot ordering, which is where most homegrown implementations break.
• De-risks the "who maintains it" conversation. Because it wraps Spatie's eloquent-sortable, the persistence logic is a widely used, independently maintained library; the package only contributes the Nova UI. Worst case, the UI is replaceable without touching the data model — that's a meaningful escape hatch for a buy decision.
• Enables a support-cost reduction, not just a feature. Every reorder currently routed to engineering as a ticket becomes a self-serve action. That's measurable: track reorder-related tickets per month before and after.
• Acceptance criteria to write into the ticket: reorder persists across sessions; move-to-first/move-to-last works; ordering holds for HasMany and pivot-backed relationships; backfilled sort_order matches existing display order so nothing visually changes on deploy; operations are safe on the current largest list in production.

When to Consider This Package

Adopt when most of these are true:

• You are already on Laravel Nova 5 with PHP ≥ 8.1. This is non-negotiable — the package pins laravel/nova: ^5.0, so it is not a reason to adopt Nova, only a reason to use Nova better.
• A human needs to curate order on small-to-medium lists — think tens to a few hundred rows, not tens of thousands.
• You need the HasMany view or pivot-based (BelongsTo/MorphsTo) reordering. That's the differentiated capability and the part most teams underestimate when building in-house.
• The ordering column is a presentation concern you can safely backfill from id (the README's own migration path), with no external system already depending on that order.
• You want localization and a maintained changelog/release cadence rather than a copied snippet.

Look elsewhere when:

• You are not on Nova. Using Filament, Livewire, or a custom admin? Use Spatie's eloquent-sortable directly with a native drag-and-drop UI. Adopting Nova to use this package is backwards.
• Lists are large or the ordering is algorithmic. Drag-and-drop on a paginated index stops being a usable interaction well before 1,000 rows, and every reorder is a write that shifts siblings. If ordering must be computed (relevance, score, multi-factor ranking) or must scale, you need a ranked/positional scoring model, not drag-and-drop.
• You need an audit trail or approval workflow on ranking changes. This package gives you the new order, not who changed it, why, or a scheduled go-live. That's a separate feature — budget for it explicitly rather than assuming it.
• Ordering is multi-dimensional. "Position within category" and "position globally" are different problems; this handles one order field well and gets awkward beyond that.
• You need an API/bulk reorder path for imports or migrations that preserve order. You'd build that on top of eloquent-sortable yourself.
• Vendor concentration is a hard constraint. Stars (~285) and publicly listed dependents (0) are modest adoption signals. MIT and a forkable surface mitigate this a lot, but if your org requires a support contract or large-community backing, this won't clear the bar.

Risk register to carry into the design review:

How to Pitch It (Stakeholders)

For executives (one paragraph): Our admin runs on Laravel Nova, which we already license. This is a free, MIT-licensed add-on that lets our content and merchandising team control the order items appear in — homepage rails, menus, featured lists, gallery items — by dragging and dropping, instead of filing an engineering ticket. It's a thin layer over a widely used open-source sorting library, so there's no lock-in and essentially no licensing cost. Estimated integration is under a day per resource. The value is speed: the team that owns the content can change what customers see first without waiting on a sprint.

For engineering (the ask): Add outl1ne/nova-sortable, add an integer sort_order column, backfill it from id so display order is unchanged on deploy, apply Spatie's Sortable trait to the model, and register the sortable index/HasMany field in the Nova resource. Confirm behavior on pivot-backed relationships if we use them. Constraint to respect: this is for human-curated order only — if a list can exceed a few hundred rows or the order should be computed, we scope that differently rather than stretching this.

The decision, stated plainly: approve as a low-cost, low-risk capability for editor-controlled ordering on Nova, with an explicit boundary that it is not our answer for algorithmic ranking, large datasets, or audited ranking changes.