Nova Sortable Laravel Package

Product Decisions This Supports

• Build vs. buy for admin-side ordering. The core question — "do we spend 2–5 engineer-days building drag-and-drop reordering into our Nova admin, or adopt a package?" — this package answers decisively toward buy for the common case. It is a thin, MIT-licensed wrapper over spatie/eloquent-sortable, so the "buy" cost is roughly a Composer require plus a trait and a ->sortable() field call, not a bespoke frontend build.
• Prioritizing "content ordering" as a shippable feature. A large share of internal admin work is CMS-shaped: banners, FAQ entries, nav links, categories, testimonials, media galleries, onboarding steps. In every one of those, the business ask is "let marketing put this in the right order without filing a ticket." This package turns a recurring, low-glamour roadmap item into a same-sprint deliverable, which makes it easy to bundle into an existing epic rather than justify standalone.
• Reducing operational/support load. Every reorder request handled by an engineer is a small tax on the team and a delay for the stakeholder. Shipping self-serve drag-and-drop converts a stream of ad-hoc tickets into a one-time build cost — a measurable input to support-load and internal-SLA discussions.
• Scope calibration on ordering complexity. The package forces an explicit product decision about how sophisticated ordering needs to be: flat or grouped-by-parent ordering (supported, cheap) versus nested trees, workflow-gated ordering, or per-tenant ordering (not supported, needs custom work). Surfacing that fork early prevents over-scoping a "just let them reorder the list" request.
• Roadmap sequencing for Nova-based products. Because it depends on Laravel Nova (a paid, version-locked dependency), adopting it is implicitly a statement that the admin surface stays on Nova. That is a platform-strategy decision worth recording alongside the feature decision.
• Vendor/risk posture for internal tooling. With ~285 stars, zero recorded dependents, and a small-agency maintainer (Outl1ne / Optimist Digital), the dependency is low-blast-radius but also low-community-support. That supports a "pin the version, isolate behind one trait, keep an exit ramp" posture rather than treating it as foundational infrastructure.

When to Consider This Package

Adopt when:

• Laravel Nova is already the admin surface. This is a hard prerequisite — the package has no value outside Nova, and Nova's per-project licensing plus major-version upgrade cadence become part of your cost of ownership.
• The models can carry a single integer/sort_order column, and ordering is flat or grouped by a single parent/foreign key (e.g., "items within a category").
• The ordering requirement is genuinely just "humans reorder this list in the admin," with no business rules attached — no approvals, no scheduled ordering, no A/B or personalized ordering.
• You want the smallest possible surface area: one field method on the Nova resource, one trait on the model, minimal code to later rip out.
• Speed matters. If the feature needs to land this sprint and the alternative is a custom Vue/Nova component, the package is a clear win.

Look elsewhere or build custom when:

• You are not on Nova. Filament ships reordering natively; a custom or Inertia/React admin needs a custom implementation; plain Blade admin needs its own JS. Using this package as a reason to adopt Nova is backwards.
• You need tree/nested-set ordering (multi-level categories, menus, page hierarchies). Reach for a nested-set package or a dedicated sortable-tree solution instead — forcing hierarchy onto a flat sort column produces fragile parent/child schemes.
• You need audited or approval-gated ordering — e.g., regulated content, merchandising changes that require review, or ordering that must be reversible with attribution.
• You need per-tenant or per-user ordering at scale. A single sort_order column with drag-and-drop writes is a coarse instrument; concurrent reorders by multiple admins will interleave, and if every tenant needs its own sequence, you are storing a matrix, not a column.
• Maintenance risk is unacceptable. Nova major-version upgrades periodically break field packages. If admin tooling is business-critical and you cannot tolerate a lag between a Nova release and a compatible package release, vendor the relevant code in-house — it is small enough to fork.
• Ordering has business semantics — e.g., it drives pricing tiers, ranking, or revenue-weighted placement — in which case you want explicit, tested, owned logic rather than a drag-and-drop field.

Adoption guardrails: verify compatibility with your pinned Nova major version before committing, prototype on one low-stakes resource first, and confirm the migration/column convention matches your existing schema so you are not introducing a second ordering pattern alongside an in-house one.

How to Pitch It (Stakeholders)

For executives (one paragraph): Content ordering in the admin — "put this banner third, move this FAQ to the top" — is a recurring request across nearly every Nova-backed product we run, and today each instance either costs engineering time or gets deferred. This package solves it in a fraction of a day: it is MIT-licensed (no procurement, no per-seat cost), it is a small add-on to the Nova admin we already pay for, and it converts a steady trickle of internal support tickets into self-service for marketing and ops. The risk profile is deliberately modest — it is a thin layer over a widely used ordering library, it touches only the admin surface and never the customer-facing app, and it is removable in an afternoon if we change course. The trade-off is that it is a small, single-maintainer open-source project, so we would pin the version and treat it as convenience infrastructure rather than a foundation. Recommendation: adopt behind a one-resource pilot, and only for resources with straightforward list ordering.

For engineering (the short version): It is a Nova field plus a model trait over spatie/eloquent-sortable. Integration is a sort_order column, a trait on the model, and ->sortable() on the Nova field. No frontend code to maintain, no new build step, no changes to domain logic or API contracts — it is confined to the Nova resource layer. Known limits: flat or single-group ordering only (not nested trees), no audit trail, and coarse concurrency if multiple admins reorder simultaneously. Watch the Nova major-version compatibility matrix before upgrading Nova, pin the package version, and keep the integration isolated to one trait so a fork or removal stays cheap. Please do a 1-resource spike and confirm the column convention before we standardize on it.