Nova Sortable Laravel Package

Technical Evaluation

Architecture fit. Unchanged and still favorable: a narrow, additive Nova index-view extension that persists an ordinal against a model column, with no core-domain or cross-service coupling. The v3.9.0 notes add one materially useful architectural fact — the ordering engine is spatie/eloquent-sortable, not bespoke logic. That reframes the package as a thin UI bridge (drag-and-drop → setNewOrder) over a mature, widely-deployed persistence trait. Net effect: slightly better fit, because the hardest correctness logic is library-owned and documented rather than hidden in a 0-star repo — but we now take a transitive dependency into the model layer, and ordering semantics become a function of the resolved Spatie major. The Nova-license and Nova-major-pin caveats still stand.

Integration feasibility. Mechanically the same: Composer install, publish assets, ordinal column, trait/scope, per-resource enablement. The important refinement is that scoping is our code, not the package's — spatie/eloquent-sortable implements tenant/parent scoping through buildSortQuery() (and order_column_name, sort_when_creating config) on the consuming model. That means the highest-severity failure mode (cross-tenant order corruption) is mitigated only if we override buildSortQuery correctly and the Nova index query is passed through. This was previously an open question about the vendor; it is now an implementation deliverable on our side, which is more controllable but also easier to get silently wrong.

Technical risk.

• Dependency-major widening inside a minor release. "Allow spatie/eloquent-sortable ^5.0" means the resolved behavior depends on the platform's Laravel/PHP versions. Two environments can legitimately resolve different Spatie majors from the same composer.json, producing different ordering behavior with no code change on our side. Pin via composer.lock and verify resolution, not constraints.
• Release provenance is still anomalous, and now more so. The earlier future-dated-release concern is compounded: several bumped versions in these notes do not correspond to published npm releases (e.g. lodash 4.18.1 — 4.17.21 is current; node-forge 1.4.0 — 1.3.1 is current; picomatch 2.3.2 — 2.3.1 is current). Either the notes are hand-edited/inaccurate or the pipeline is synthesizing them. Verify the tag, the diff, and the tarball against the registry before adopting.
• Laravel 13 support is leading-edge. The package is tracking a Laravel major ahead of most production platforms. Good sign of activity; bad sign for "boring" dependency. Confirm it still supports our actual Laravel/PHP floor rather than only the newest.
• Adoption signal unchanged (no star/dependent data supplied). Mitigated — not resolved — by visible dependabot merge activity and a named maintainer (@stefvanesch); bus factor is still effectively one.
• Native overlap risk (Nova sortable flags / sortable BelongsTo) — unchanged; still the first thing to rule out.
• Version lock on Nova asset layer (Vue 2 vs Vue 3 across Nova majors) — unchanged.
• Correctness under concurrency. v3.9.0 does not address this. Upstream Spatie ordering writes are per-model updates rather than a single bulk statement, so simultaneous drags can interleave; transactional wrapping and deterministic ordering remain our responsibility.
• Pagination and filtered views — unchanged UX trap; positions computed from a partial result set are still wrong.
• Bundle churn. The webpack 5.90.3 → 5.105.0 bump can change emitted asset filenames/hashes; upgrading without a clean re-publish can leave stale JS mounted in Nova.

Key questions.

1. Which spatie/eloquent-sortable major resolves on our platform, and what changes between v4 and v5 in scoping, sort_when_creating, and write behavior?
2. Who owns buildSortQuery() per resource, and does it cover tenancy, parent relations, and soft deletes?
3. Are the v3.9.0 tag, diff, and asset bundle verifiable against the registry, given the anomalous version strings in the notes?
4. What Laravel/PHP floor does v3.9.0 actually declare, and do we sit inside it?
5. What is the write pattern on reorder (per-model loop vs bulk) and is it transactional?
6. Is reordering authorization-gated (policy/ability), or does any Nova user with index access gain reorder rights?
7. Does native Nova sortable already satisfy the requirement? If yes, this is out of scope.

Integration Approach

Stack fit. Unchanged: good for Laravel + Nova resources carrying a stored ordinal; poor for derived ordering (computed rank, relevance, alphabetical) or lists primarily consumed via APIs where order is a versioned domain concern. Classify each candidate resource as "stored ordinal," "derived," or "no ordering need" before committing.

Migration path. Still an experiment, not a dependency:

1. Add the nullable ordinal column, deterministic backfill per scope, composite index on (scope_columns, order).
2. Install the trait and implement buildSortQuery() explicitly per model — treat this as the primary engineering task, not configuration.
3. Keep the existing numeric order field editable as a fallback during the trial.
4. Enable drag-and-drop behind a per-resource feature flag.
5. Preserve the exit: if native Nova sortable covers the need, the column, backfill, and buildSortQuery() survive — only the UI binding swaps.

Compatibility. Pin both the Nova package and spatie/eloquent-sortable; commit and verify composer.lock in CI, and test resolution at both the lowest and highest supported Laravel/PHP. Validate on a production-shaped staging clone: multi-tenant rows, soft-deletes, a parent/child resource, and every database engine in use. Add an explicit deploy step that republishes assets and asserts no stale bundle remains in public/vendor/nova — this release is bundle-only churn, so it is exactly the release most likely to drift silently.

Sequencing.

1. Spike (1–2 days): native Nova sortable comparison; read the reorder endpoint, confirm the resolved Spatie major and its scoping hooks.
2. Provenance check (hours): verify tag/diff/asset bundle; diff v3.8.1 → v3.9.0 yourself rather than trusting the notes.
3. Prototype (3–5 days): one low-risk resource, feature-flagged, with backfill, index, and buildSortQuery().
4. Correctness QA: two simultaneous drags; scoped reorder under tenancy; filtered/paginated views; permission boundaries; soft-delete gaps; upgrade-then-republish asset check.
5. Canary: internal admins only, one week, with a reorder audit log.
6. General rollout: resource by resource; keep the numeric fallback for two clean release cycles.

Operational Impact

Maintenance. Slightly better than previously assessed: the ordering logic has a real upstream with documentation and a release history, and the dependabot merges — several of them security-driven (node-forge, follow-redirects, serialize-javascript, minimatch) — are evidence someone is tending the asset toolchain. But the bumps confirm the bundle is rebuilt frequently, so each upgrade requires an asset re-publish and a visual smoke test. Budget a few hours per quarter, plus a checkpoint at every Nova major and every Spatie major.

Support. No vendor SLA, but the escalation path now has a real terminus: Spatie's package for ordering semantics, our own code for buildSortQuery() and the Nova binding. Document the ordering policy and the per-model scope query internally so support can answer "why is this row here" without reverse-engineering a third-party bundle.

Scaling. Unchanged in shape: cost scales with rows whose positions shift, not with drags. Because upstream ordering writes are per-model rather than one bulk statement, large reorders hold locks longer — acceptable at admin scale (thousands of rows), risky beyond. Read paths are unaffected.

Failure modes.

• Scope leakage: missing or incomplete buildSortQuery() → cross-tenant ordering corruption. Highest severity; now our defect, not the vendor's.
• Dependency resolution drift: different Spatie majors on different hosts → divergent ordering behavior with an unchanged codebase.
• Duplicate or gapped ordinals after concurrent drags, deletes, or failed transactions.
• Asset drift / stale bundle after upgrade, especially given the webpack bump and possible filename changes.
• Silent UI breakage on Nova upgrade while persistence still works.
• Filtered/paginated reorder writing positions from a partial result set.
• Unauthorized reorder if the action is not policy-gated.
• Supply-chain ambiguity if the anomalous release metadata is not independently verified.

Ramp-up. Developer ramp-up remains hours; familiarity with spatie/eloquent-sortable is common, which lowers it slightly. Product/admin ramp-up still requires a written ordering policy (what "order" means per resource, who may change it, what happens on create). Keep the reorder audit trail from day one.