Ea Sortable Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for back-office ordering. The package's job is narrow and well-defined: let an admin reorder records (drag-and-drop) in an EasyAdmin CRUD screen and persist that order to the database. That is a classic "don't build it yourself" candidate — the custom build is usually 1–2 sprints of UI plus a sort-index column, reindex-on-delete logic, and concurrency edge cases that nobody budgets for.
• Feature/roadmap scoping. This unlocks "manually curated ordering" features cheaply: merchandising order for products/categories, editorial sequencing of articles or pages, navigation/menu ordering, priority or featured lists, FAQ and documentation ordering. If any of those sit on the roadmap, adoption can compress the estimate rather than expand it.
• Platform fit is the real decision, not the feature. Despite being a PHP/Composer package, this is a Symfony / EasyAdmin / Doctrine bundle from a single vendor (Torfs ICT), not a Laravel package. The product decision is therefore less "should we use this library" and more "which admin stack are we standardizing on" — a decision with much longer half-life.
• Maintenance-risk posture. 1.0.1 is a patch increment off 1.0.0 with auto-generated release notes ("Full Changelog" link only, no described fixes, no CVE or deprecation notice). Read that as: the project is maintained, but release communication is thin and the API is pre-2.0. Plan for the possibility of upstream stalls and keep the ordering feature behind a thin internal abstraction so it can be swapped.
• Vendor/exit-cost sizing. Small single-vendor bundles are cheap to adopt and cheap to exit only if you don't let their assumptions leak into your domain model. Budget a short spike to read the 1.0.0→1.0.1 diff and the sort-index implementation before committing it to a customer-facing roadmap item.

When to Consider This Package

Consider it when all of the following hold:

• The application is Symfony with EasyAdmin admin screens backed by Doctrine ORM entities.
• Users genuinely need manual, human-curated order rather than a computed sort (relevance, recency, sales rank).
• The lists are small-to-moderate and admin-edited (tens to low thousands of rows per list), not high-frequency programmatic reordering.
• You want the ordering affordance in the admin UI out of the box, without owning the JavaScript or the reindexing logic.
• You can tolerate a 1.0.x, single-vendor dependency and are willing to read the compare diff yourself, since the release notes won't tell you what changed.

Look elsewhere (or build) when:

• You are on Laravel — this is the wrong ecosystem. Use spatie/laravel-sortable or the native reordering in Filament / Laravel Nova instead; forcing a Symfony bundle in costs more than the feature is worth.
• You need ordering in a public-facing or API surface, or ordering driven by rules/analytics rather than humans.
• You need multi-tenant or scoped ordering (different order per storefront, locale, or customer segment) — verify this explicitly rather than assuming; scoped sort indexes are a common gap in small sortable bundles.
• You need an audit trail of who reordered what, or optimistic concurrency guarantees when two admins drag at once.
• You need very large lists, bulk imports that must preserve order, or reordering as part of a data migration — the per-row index rewrite pattern tends to be the bottleneck.
• You require vendor SLAs, security disclosure process, or long-term support — a single-vendor pre-2.0 bundle won't provide them.

How to Pitch It (Stakeholders)

To executives (one paragraph): This is a small, free, open-source add-on that gives our back-office team drag-and-drop control over the order items appear in — merchandising order, menu order, editorial sequencing — without us building and maintaining that capability ourselves. Version 1.0.1 is a patch release, so it carries no expected breaking changes and no migration cost. The trade-off is maturity: it is a pre-2.0, single-vendor component with sparse release notes, so we'd adopt it behind a small internal wrapper and treat it as replaceable rather than foundational.

To engineering (one paragraph): Composer-installable Symfony bundle for EasyAdmin that adds sortable behavior to Doctrine entities — install, enable on the relevant CRUD controllers, add the sort column, ship. The 1.0.1 release is patch-level off 1.0.0 with an auto-generated changelog only, so the concrete ask before merge is: read the 1.0.0...1.0.1 compare diff, confirm EasyAdmin/Doctrine version compatibility, and confirm the sort-index rewrite strategy and behavior on delete. Keep our ordering logic behind an interface so a swap (or a hand-rolled implementation) is a contained change, and add a test that covers reorder persistence and deletion reindexing so an upstream patch can't silently regress curation order.