Nova Sortable Laravel Package

Technical Evaluation

Architecture fit

• Purpose-built UI enhancement for Laravel Nova 5 index views; it does not introduce a new data layer or service boundary. It is a thin Nova field/tool wrapper over spatie/eloquent-sortable, which is already a de facto standard in the Laravel ecosystem.
• Fits cleanly into an existing Nova-based admin plane: the model gains the Sortable trait, a sort_order column is added, and NovaSortable is dropped into the resource definition. No changes to APIs, queues, or domain services are required.
• Coupling is two-dimensional: the package locks to laravel/nova:^5.0 and transitively to a specific spatie/eloquent-sortable major. Both are upgrade-sensitive.

Integration feasibility

• Effort is low: one Composer install, one additive migration, one trait, one resource field. A Laravel developer can pilot this in under a day.
• The only non-trivial work is data backfill (UPDATE ... SET sort_order = id) and deciding the correct sortable scope (global vs. per-parent/per-category), which is where most misconfigurations occur.
• Pivot/MorphsTo support means many-to-many ordering is achievable without custom code, but it implies a second migration for the pivot sort_order column and careful scope definition.

Technical risk

• Nova licensing/version lock — Nova is commercial. If the org is on Nova 4, this package is a hard blocker until a Nova 5 upgrade lands. Treat Nova 5 as a prerequisite, not a side effect.
• Maintenance concentration — single-vendor (outl1ne), ~285 stars, MIT, no SLA. Recent releases and changelog are positive signals, but bus factor is 1–2. The dependents: 0 figure is likely an artifact of Nova's closed ecosystem and should not be read as zero adoption.
• Concurrency — drag-and-drop reordering writes position values without optimistic locking. Two admins reordering the same list concurrently can produce inconsistent sequences. Low frequency, but real.
• Backfill correctness — nullable or non-backfilled sort_order produces non-deterministic ordering, which surfaces as "phantom bugs" in the admin UI.
• Blast radius — scoped to the admin plane; a failure degrades ordering UX, not transactional integrity.

Key questions

• Do we already hold Nova 5 licenses, and is every target resource on Nova 5 today?
• Which resources need ordering, and is order global or scoped (per parent, per tenant, per locale)?
• What is the max row count per sortable set? (drives whether drag-and-drop is viable at all)
• Do any target tables already have an ordering column or implicit created_at-based ordering we'd be replacing?
• Are there custom Nova index views or fields that could conflict with the injected drag-and-drop assets?
• Do we need an audit trail for who reordered what, and when?

Integration Approach

Stack fit

• Assumes Laravel + Nova 5 + PHP 8.1+, MySQL/Postgres. No frontend build changes, no separate service, no new infrastructure. Composer-only dependency.
• Aligns with existing Spatie usage if eloquent-sortable is already present; otherwise it becomes a new transitive dependency pinned by the package.

Migration path

1. Baseline the current ordering behavior (explicit column vs. implicit id/created_at) per resource — this defines "correct" before and after.
2. Add sort_order as a nullable integer, backfill deterministically (copy id or created_at rank), then enforce non-null and add a composite index on (scope_column, sort_order).
3. Implement Spatie\Sortable\Sortable on the model, define $sortable scope columns, and register NovaSortable in the resource.
4. Repeat for pivot-backed relationships only where the UX actually requires it.

Compatibility

• Hard gates: Nova ^5.0 and PHP >=8.1. Verify the pinned spatie/eloquent-sortable major is compatible with the app's Laravel version before committing.
• Watch for conflicts with other Nova index customizations (custom fields, resource tools) that manipulate row rendering.

Sequencing

• Phase 1: Nova 5 readiness audit; confirm licensing and identify any resources still on Nova 4.
• Phase 2: Staging pilot on one low-risk, low-volume resource; validate ordering persistence, scope isolation, and localization.
• Phase 3: Backfill migrations for the remaining resources, with a documented rollback (dropping the column restores prior behavior only if the previous default ordering was id).
• Phase 4: Roll out resource-by-resource behind normal release cadence; add feature tests asserting order after move operations.

Operational Impact

Maintenance

• Near-zero recurring maintenance in steady state; the surface is a resource field and a trait. The real cost is upgrade coupling: every Nova major and every eloquent-sortable major becomes a coordinated upgrade.
• Pin versions in composer.json and track the package's changelog; a single-maintainer MIT package should not be allowed to float.

Support

• Community-only support via GitHub issues; no vendor SLA, no paid tier. Acceptable for an admin-plane convenience feature, unacceptable for anything user-facing or revenue-critical.
• Mitigation: fork-and-patch capability is realistic given the small codebase; assign an internal owner.

Scaling

• eloquent-sortable rewrites only the rows between the old and new positions, so per-move cost scales with drag distance, not total table size. Lists in the low thousands are typically fine; tens of thousands are not appropriate for drag-and-drop UX regardless of package.
• Add the composite (scope, sort_order) index up front — missing it turns every reorder into a table scan on the scoped set.
• Scoped ordering (per parent/tenant) is the primary lever for keeping sets small; global ordering on a large table is the failure pattern.

Failure modes

• Concurrent reorders producing duplicate or gapped sort_order values → non-deterministic display order.
• Null/absent backfill → items render in arbitrary order after the migration.
• Misconfigured scope → items from different parents interleave; can look like cross-tenant data mixing in the index view.
• Nova version drift → JS assets fail to load or drag-and-drop silently no-ops after an upgrade.
• Migration lock on large tables when adding the column and backfilling in a single transaction.

Ramp-up

• Trivial for any Laravel developer: the README pattern (migration → trait → resource field) is idiomatic and well documented, with localization support.
• The genuine ramp-up is team convention: documenting which resources are sortable, what each scope means, and the backfill procedure so it isn't reinvented per resource. Budget one short internal doc and a code-review checklist item rather than formal training.