Laravel Sortable Laravel Package

Product Decisions This Supports

• Whether to ship manual ordering in v1. Any product surface where the customer's intent order differs from creation order — CMS pages, navigation menus, FAQ lists, featured carousels, kanban columns, onboarding checklists, pricing tiers — needs a persisted position column plus move semantics. This package is a candidate implementation for that slice.
• Build vs. buy for a ~150-line concern. The capability is a trait, a position column, and move/swap methods. That is cheap to write in-house. The decision is less "is this package good" and more "does adopting it save us a sprint, and what does it cost us at upgrade time."
• Scoping the curation UX. Because the package handles only persistence and move operations, it forces an explicit decision about who owns drag-and-drop rendering, optimistic UI, conflict handling, and authorization (who may reorder what). Those are the expensive parts; the model layer is not.
• Multi-list ordering as a roadmap question. Group-scoped ordering (items ordered within a parent, e.g. sections within a page) is a materially different data model than a single global list. The package's group support lets you defer that decision cheaply, but the schema choice is hard to reverse later.
• Concurrency and position integrity as a quality bar. Decide up front whether reordering must be safe under simultaneous editors. Most implementations of this pattern (including this one) reindex or swap without row-level locking, so "no lost updates with two admins" is a product promise you'd have to build yourself regardless of package.

When to Consider This Package

• Narrow fit: a Laravel 5.x-era application, single-database, low-concurrency admin-only reordering, and a team that wants a working trait today rather than a designed one.
• As a reference implementation, not a dependency. The MIT license and small surface make it reasonable to read, vendor, and rewrite against current Laravel. That is the strongest use case given the signals below.
• Look elsewhere if any of these hold:
  • Maintenance risk is disqualifying. Last release 2016-11-17 places it roughly Laravel 5.3 era. Modern Laravel (9/10/11/12) and PHP 8.1+ changed enough — type declarations, deprecations, container and query-builder internals — that this will likely need patching before it runs. An unmaintained dependency in the model layer is a persistent tax.
  • Adoption signals are effectively zero. 1 star, 0 dependents, score 0.005. There is no community to catch regressions, no issue traffic to mine, no downstream code proving it works. You are the only user.
  • You need concurrency safety, audit history, or bulk reordering at scale. Gap-based ordering, fractional positions, or event-sourced ordering changes are not in scope here.
  • A maintained equivalent exists. spatie/eloquent-sortable covers the same ground with active maintenance — evaluate it first and treat this package as the fallback or the design reference.
  • Diligence flag: the metadata is internally inconsistent — package name sofa/laravel-sortable, repository jarektkaczyk/eloquent-sortable, and metrics that don't match the well-known project of that name. Confirm you're evaluating the artifact you think you are before it enters the build.

How to Pitch It (Stakeholders)

For executives: We need manual ordering in several places — menus, featured content, onboarding steps. The persistence layer for that is small and well understood; a candidate open-source package exists under a permissive MIT license. However, it was last released in 2016, has essentially no adoption, and will not run unmodified on our Laravel version. Recommendation: do not take it as a dependency. Either implement the ordering trait in-house (roughly one to two days of engineering, fully owned) or adopt the actively maintained equivalent. The decision is low-stakes in effort but worth getting right, because a stale package pinned into our models becomes an upgrade blocker for every future Laravel major.

For engineering: The package provides a Sortable trait — a position column, ordered query scopes, and move/swap operations, with optional grouping. It is a reference design, not a dependency. It predates modern PHP/Laravel typing and has no maintenance or downstream usage to validate against. Prefer an in-house trait or a maintained alternative; if we do reuse it, vendor and rewrite, and add row locking plus a uniqueness constraint on (group, position) so concurrent reorders can't corrupt ordering.