Nova Field Sortable Laravel Package

Technical Evaluation

Architecture fit This is a Nova field package — a presentation-layer extension to Laravel Nova's admin UI, not domain logic. It sits on top of spatie/eloquent-sortable (the maintained dependency that supplies the Sortable trait, sort_order column convention, and ordered scopes) and adds a drag-handle column to the Nova resource index. Architecturally it is low-invasiveness: adopting it means accepting one column convention (sort_order) on selected tables plus a Nova field registration. That is a reasonable pattern and independently useful even if the package is later dropped.

Integration feasibility Mechanically trivial: composer require, add the trait to the model, add sort_order via migration with a deterministic backfill, register the field in fields(). Realistic effort is well under a day for a Nova-fluent developer. The blocker is not effort, it is version alignment and provenance, not code volume.

Technical risk — high, and mostly not about code quality

• Abandonment. Last release 2021-06-11. That predates Nova 4 (Vue 3 frontend, rebuilt field toolchain) and Nova 5. Nova field packages are tightly coupled to Nova majors; a 2021 field almost certainly does not work on Nova 4/5, and its composer constraints may be loose enough to install and then fail at runtime.
• No ecosystem signal. 3 stars, 0 dependents, single maintainer. There is no crowd to have already found the breakages, and GitHub's dependency graph will not surface advisories for a package nobody depends on.
• Fork provenance unverified. A "forked from naxon/nova-field-sortable" with this little traction may be a vanity fork with zero or cosmetic deltas from upstream — in which case it adds no value over the original and may not even be published to Packagist. This must be diffed before any decision.
• Score corroboration. The 0.135 package score and 32.18 opportunity score line up with the qualitative read: low maturity, low strategic leverage, negligible community support.
• Data-integrity risk, not just UX risk. Reorder correctness under filtering, pagination, and multi-tenant scoping is the classic failure mode for these fields; a broken drag interaction is visible, a mis-scoped order write is silent.

Key questions

1. Which Nova major are we on today, and is a Nova upgrade in the next 18 months?
2. What is the actual diff between this fork and naxon/nova-field-sortable? Is it published on Packagist, or would we pin a VCS commit?
3. What does it declare for laravel/nova and spatie/eloquent-sortable, and does that constraint prevent an incompatible install or merely permit it?
4. Is reordering scoped (sort within a parent/tenant) and does it behave correctly on a filtered or paginated index?
5. Are compiled JS assets committed, or does the consumer need a Node build step we'd have to maintain?
6. Who owns patching this when Nova moves — and do we have the Nova license seats/upgrade path that assumption depends on?

Integration Approach

Stack fit Laravel + Nova + spatie/eloquent-sortable. Assume Laravel 8/9-era and PHP 7.4/8.0 compatibility; treat Laravel 10/11 and PHP 8.2+ as unverified until tested. Fit is good only if we are on a Nova 3-era install; on Nova 4+ assume non-functional until proven otherwise.

Migration path (additive, no replacement)

1. Timeboxed spike (≤1 day) on a branch: install, diff against upstream, confirm the field renders and persists on our actual Nova version.
2. Add sort_order column plus a deterministic backfill (ordered by existing created_at/id) in the same migration so no row is left null.
3. Add the trait and field to one low-risk resource first.
4. Verify reorder persistence, filtered-index behaviour, and scoped sorting before widening.
5. If the spike fails, stop — do not "make it work" by pinning Nova.

Compatibility and alternatives Maintain a small compatibility matrix (Nova major × Laravel × PHP) and record the verified cell. If the spike fails, the realistic options in preference order are: (a) evaluate an actively maintained Nova sortable field — outl1ne/nova-sortable is the obvious candidate to screen, since it tracks Nova 4/5; (b) build a thin in-house field over spatie/eloquent-sortable (~1–2 dev-days, and we own the upgrade path anyway); (c) fall back to a plain numeric sort_order text field — no drag affordance, zero dependency risk. Because the license is MIT, vendoring the fork's code as a starting point is legitimate, but only if we accept ownership explicitly.

Sequencing Spike → decision → backfill migration → single-resource rollout → documentation. Gate the whole thing on the Nova upgrade roadmap: if Nova 4/5 is within 18 months, do not build on this package.

Operational Impact

Maintenance Effectively unowned upstream; adopting it means we own it. Every Nova major becomes a small internal fork project. Budget that as recurring cost, not a one-off install. The one durable asset is the sort_order column convention, which survives dropping the package.

Support and ramp-up No vendor, no SLA, negligible community. Ramp-up for a Laravel/Nova developer is an afternoon — there is no new mental model beyond the spatie trait — but the knowledge will be concentrated in whoever ran the spike. Document the version matrix and the fork diff in the repo.

Scaling Drag-and-drop reorder is appropriate for bounded, curated lists — navigation menus, categories, homepage sections, FAQs — not high-cardinality tables. On large datasets the index listing and reorder interaction degrade, and bulk position rewrites get expensive. Keep it off any table expected to grow into the tens of thousands of rows.

Failure modes to watch

• Silent break on Nova upgrade: the Vue component fails to register; index still renders, handle column is blank or console-erroring. Fails quietly in production, not at deploy.
• Overly permissive composer constraint: incompatible version installs cleanly, breaks at runtime.
• Null sort_order from manual inserts or seeders → unstable, non-deterministic ordering.
• Concurrent reorders: no optimistic locking; two admins dragging simultaneously produce lost updates. Acceptable for a single-editor CMS, not for a busy admin.
• Scoping bugs: reorder inside a filtered subset or a tenant writing global positions — silent data corruption rather than a visible error.