Ea Sortable Bundle Laravel Package

Technical Evaluation

Architecture fit. torfs-ict/ea-sortable-bundle is a Symfony bundle, not a Laravel package. Its name and upstream namespace indicate it hooks into EasyAdmin (the Symfony admin generator) to provide drag-and-drop ordering of Doctrine entities via a persisted position column. There is no Illuminate\Support\ServiceProvider, no Laravel package auto-discovery entry, no published config/migration stubs, and no Eloquent integration. On a Laravel codebase the package is not installable in any meaningful sense — it can be pulled as a Composer dependency, but its bundle class will never be registered and its behaviour will never execute. Architecture fit is therefore effectively zero for direct adoption; the only realistic value is as a reference implementation for the sortable-position pattern (position column + reorder endpoint + SortableJS front end).

Integration feasibility. Direct: not feasible. Indirect (porting the pattern into Laravel) is feasible and is a small, well-understood piece of work — a position integer column, a reorder controller action accepting an ordered ID list, and a transaction that rewrites positions. Effort is measured in days, not weeks, but it is our code, not the vendor's, so the dependency buys us only design guidance.

Technical risk. Several compounding risks:

• Opaque release. 1.0.1 ships with no release notes beyond an auto-generated compare/1.0.0...1.0.1 link. We cannot determine from the release metadata whether this is a bug fix, a dependency bump, a security patch, or a CI-only change. Any assessment of the delta is speculation until the diff and CHANGELOG.md are read.
• Pre-2.0 API surface. At 1.0.x, semver permits breaking changes only at 2.0, but small vendors frequently treat minor/patch releases loosely. Pin exact versions if anything ever depends on this.
• Single-vendor, retail-origin project. torfs-ict is a retailer's ICT org publishing an internal tool. Expect low release cadence, limited issue triage, and a high bus factor.
• Framework coupling. Deep coupling to EasyAdmin's field/controller internals makes it sensitive to EasyAdmin major versions (v3 → v4 was disruptive), which is irrelevant to us but signals the maintenance surface.

Key questions.

1. What is actually in 1.0.1? Read the diff and CHANGELOG.md — do not accept the release page as the record.
2. Which EasyAdmin and PHP versions does 1.0.1 constrain? (Only relevant if we are evaluating a Symfony service.)
3. Is the position column strategy contiguous-integer, sparse, or fractional/lexicographic? This determines reorder write amplification.
4. License terms and whether the reorder logic is cleanly separable from EasyAdmin controllers.
5. Is there any maintained Laravel equivalent (spatie/laravel-sortable, spatie/eloquent-sortable) that removes the need to port at all?

Integration Approach

Stack fit. Mismatch. Target stack is Laravel/PHP with Eloquent; the package assumes Symfony DI, Doctrine ORM, Twig, and EasyAdmin routing. There is no adapter layer worth writing — bridging Doctrine to Eloquent for a feature this small is strictly more work than reimplementing it.

Migration path. There is nothing to migrate from or to; this is a pattern adoption, not a package adoption:

• Add a position (or sort_order) unsigned integer column plus an index on (parent_id, position) if ordering is scoped.
• Expose a POST /{resource}/reorder endpoint accepting an ordered array of IDs; validate membership and authorization before writing.
• Wrap the rewrite in a transaction; use SortableJS on the front end, mirroring what the bundle does with EasyAdmin's assets.
• Consider spatie/eloquent-sortable, which implements exactly this for Eloquent and is actively maintained — this is the recommended substitute, and it makes the Symfony bundle redundant.

Compatibility. Unknown and unverifiable from the release notes. If the Symfony path is ever revisited, compatibility must be established against the pinned EasyAdmin minor, not the package's own semver alone.

Sequencing.

1. Read the 1.0.1 diff and changelog (30 min, blocking any decision).
2. Confirm whether the evaluation is even in scope — if the target application is Laravel, close this as "not applicable" and redirect to spatie/eloquent-sortable.
3. If a Symfony service is in scope, spike the bundle against a pinned EasyAdmin version in a throwaway app.
4. Only then decide build-vs-adopt; do not sequence this ahead of higher-value platform work.

Operational Impact

Maintenance. Adopting the bundle externally means inheriting a dependency whose release communication is a bare changelog link. We would be unable to assess upgrade risk without reading diffs manually — an ongoing tax on every patch release, disproportionate to the feature's value. If we port the pattern instead, maintenance is ours and trivially small.

Support. No commercial support, no SLA, no visible security policy. Issue response times should be assumed to be best-effort and volunteer-adjacent.

Scaling. Sorting features have a predictable scaling profile worth flagging regardless of implementation: a drag-and-drop reorder rewrites N rows, so cost grows linearly with collection size and holds row locks for the transaction duration. For collections in the low hundreds this is negligible; beyond that, prefer sparse or fractional ordering so a single drag writes O(1) rows. Concurrent reorders from two admin sessions are the classic failure mode and require either optimistic locking or last-write-wins acceptance — decide explicitly.

Failure modes.

• Concurrent drag operations producing duplicate or gapped positions.
• Partial reorder commits if the transaction boundary is drawn incorrectly (a bundle-internal concern we cannot audit from the release notes).
• Silent breakage on EasyAdmin upgrade (Symfony path only).
• Assessment failure mode: treating an empty release note as evidence of a low-risk patch. 1.0.1 is unknown risk, not low risk, until the diff is read.

Ramp-up. Negligible for the pattern; significant for the Symfony bundle if the team is Laravel-only. Realistically the ramp-up cost exceeds the cost of implementing sorting directly, which is the decisive operational argument against adoption.

Verdict on 1.0.1. The patch release carries no actionable information, so it does not change any conclusion — but it does reinforce the governance concern: a dependency that publishes no release notes is a dependency we cannot safely track. Recommendation stands as do not adopt; reuse the pattern or use spatie/eloquent-sortable, and re-evaluate only if the 1.0.1 diff reveals a security fix relevant to a Symfony service we actually run.