Sortable Behavior Bundle Laravel Package

Product Decisions This Supports

• Feature scoping for admin-managed ordering. Manual sequencing of lists — categories, nav items, banners, FAQs, plan tiers, workflow steps, media galleries — is a commodity capability with high user expectations and near-zero differentiation. This package is a concrete data point for pricing that feature rather than inventing scope.
• Build vs. buy triage. The artifact embodies the standard "position column + adjacent swap" pattern. Its existence lets us benchmark the in-house alternative (typically days, not weeks) instead of opening a dependency-review cycle for a solved problem.
• Upgrade-risk budgeting. Last release 2020-10-16 with 0 stars and 0 dependents means the next PHP/Symfony major bump is our problem, not a maintainer's. That converts an invisible future tax into a present roadmap item: own it, replace it, or drop the feature.
• Stack-fit correction. Despite being framed as a Laravel/PHP package, the repository is a Symfony bundle built around Doctrine-style "behaviors." For a Laravel codebase the decision is "reimplement the concept, do not port the code" — the swap semantics transfer; the implementation does not.
• Design reference. Field naming, reorder endpoint shape, and admin-integration points are useful inputs to an internal spec even if the package is never installed.

When to Consider This Package

Consider it only when all of the following hold:

• The stack is Symfony + Doctrine ORM with an admin bundle from the same family and a matching pinned framework version.
• We are willing to fork-and-own: vendor the code, add CI against our PHP/Symfony matrix, and carry compatibility patches ourselves.
• The need is simple, single-scope ordering over small lists — no audit trail, no concurrent-reorder guarantees, no multi-tenant scoping.

Look elsewhere, or decline, when:

• The codebase is Laravel/Eloquent. Incompatible by design; use a maintained sortable trait or a position column with a swap endpoint.
• We are on Symfony 6/7 or PHP 8.2+. No evidence of support in a five-year-old release.
• Procurement or security review requires a maintained upstream. Zero dependents means zero external scrutiny; single-maintainer org fork means no continuity guarantee.
• Ordering is a real product surface — large tables, tenant-scoped sequences, frequent reorders — which needs position rebalancing, DB constraints, and optimistic locking that this package does not evidence.

How to Pitch It (Stakeholders)

Executives: This is a free, MIT-licensed building block for admin list ordering, but in practice it is an org-internal fork with no adoption and no release since 2020. Its continuity and upgrade risk is disproportionate to the value of the feature it delivers. Recommendation: do not adopt. Budget one to two engineering weeks to implement ordering natively, which removes the dependency and the bus-factor risk outright. The package's value to us is as a design reference, not as a supplier.

Engineering: Treat it as a fork to be owned, not a library to be consumed — pin the commit, stand up CI on our PHP/Symfony matrix, and test the swap logic directly. Confirm target framework first: this is a Symfony/Doctrine bundle, so any Laravel assumption in the ticket is a scoping error, not a research task. If we remain on Symfony, the credible alternative is a few hundred lines of position field plus reorder endpoint that we control and can extend for scoping and auditability.