Admin Positionable Bundle Laravel Package

Technical Evaluation

Architecture fit — poor, and the premise needs correcting. Despite the "Laravel/PHP package" framing, fsi/admin-positionable-bundle is a Symfony bundle, not a Laravel package. It ships as FSi\Bundle\AdminPositionableBundle, registers through Symfony's DI container and bundle system, and is a satellite of the FSi AdminBundle CRUD suite. There is no service provider, no facade, no config publishing, and no Laravel auto-discovery. Nothing about its integration surface maps onto Laravel's package model.

Integration feasibility — low as a drop-in, moderate as a design reference. A composer require will pull Symfony components and likely conflict with the framework's own dependency graph. The realistic path is a clean-room reimplementation of the ~one behavior it provides: computing a target position and shifting siblings within a transaction. The package's actual value to us is the specification of the UX (increase/decrease position actions on a list), not the code.

Technical risk — high, concentrated in abandonment.

• Last release 2019-08-07; the codebase is from the PHP 7.1 / Symfony 3.4–4.x era. Expect symfony/*: ^3.4|^4.0 and php: ^7.1 constraints that will not resolve against Laravel 10/11 (Symfony 6/7).
• 1 star, 0 dependents — zero community validation, no downstream users to inherit bug fixes from, no security triage.
• Single-organization maintenance (FSi Open); the surrounding AdminBundle ecosystem is effectively dormant.
• MIT license is clean, so forking/porting carries no legal friction — the risk is purely technical debt.

Key questions for the business:

1. Is the requesting team actually on Laravel, or is this a Symfony shop where the bundle genuinely fits? This determines whether the work is "install" or "port."
2. What is the real requirement — manual drag/up-down ordering in an admin table? If so, an established Eloquent sortable package covers it in hours.
3. Do we need ordering to be collision-safe under concurrent admin edits, or is single-editor usage assumed?
4. Is there an existing FSi AdminBundle investment we must preserve the UI contract for? If not, the bundle's abstractions are dead weight.

Read on the scores: an opportunity score of 4.15 against an overall 0.315 is the classic signature of a real, recurring need served by an unmaintained artifact — manual list ordering is a near-universal admin requirement, and this package is the only thing that names it. That argues for building the capability, not adopting this code.

Integration Approach

Stack fit — no direct fit. Laravel's idioms (service providers, Eloquent, Blade/Livewire/Inertia) have no counterpart to Symfony bundles plus Doctrine listeners. The bundle's positioning logic is entangled with Doctrine event subscribers and FSi AdminBundle's list view layer; both must be discarded.

Recommended migration path — port the behavior, not the package.

1. Adopt an existing Eloquent sortable implementation (e.g. spatie/eloquent-sortable) as the persistence primitive; it covers the position column, sibling shifting, and query scopes.
2. Reimplement only what the bundle uniquely contributed: the increase/decrease action semantics and whatever authorization/UI affordances surrounded them.
3. Preserve the MIT attribution if any code is copied verbatim into a fork.

Compatibility checks to run before any decision:

• Inspect composer.json for symfony/* and php constraints — this alone will likely end the "install it" option.
• Confirm whether Doctrine ORM/ODM and gedmo/doctrine-extensions Sortable are hard requirements; if so, the port surface is larger than it appears.
• Verify the position column semantics (0-based vs 1-based, gap handling) so migrated data matches the new implementation.

Sequencing:

1. Requirement confirmation and UX sign-off (up/down buttons vs drag-and-drop) — half a day.
2. Timeboxed spike on an Eloquent sortable package — 1–2 days; this is where the decision is actually made.
3. Schema migration to add/backfill a position column and a (parent_id, position) index.
4. Controller/endpoint plus UI wiring, with transactional move semantics.
5. Concurrency and regression tests before rollout.

Realistic effort for a Laravel port: 2–4 developer days, not including UI polish. That is almost certainly cheaper than fighting the dependency graph.

Operational Impact

Maintenance — we own it either way. There is no upstream to lean on; the last release is six years old. If we fork, we inherit security patching, PHP-version bumps, and framework upgrades indefinitely. If we port to Eloquent, the maintenance burden drops to a thin wrapper over a maintained package — a materially better position.

Support — effectively zero. No active maintainer cadence, no issue triage, no documented upgrade path. Do not place this in a critical path expecting vendor response. Any incident is self-resolved by our team.

Scaling — the naive algorithm is the constraint. Position shifting rewrites every sibling row on each move: O(n) writes per operation. Fine for admin lists in the hundreds; problematic for lists in the tens of thousands or for high-frequency reordering. If scale is a concern, use sparse/gap-based positions or fractional indexing so a move touches one row instead of n.

Failure modes to design against:

• Duplicate positions under concurrent moves — two admins reordering simultaneously produce collisions. Require a transaction plus row-level locking, and add a unique constraint on (scope, position) as a backstop.
• Position gaps and drift after deletes or partial failures; include a periodic compaction job or accept gapped ordering by design.
• Semantic mismatch on data migration if the existing position column's base and gap strategy differ from the new implementation.
• Event-listener divergence — Doctrine's sortable listener and Eloquent's model events behave differently around bulk updates; test insert, delete, and reorder paths explicitly.

Ramp-up — low for the concept, moderate for the port. Any senior Laravel developer understands ordered lists; the onboarding cost is in auditing the bundle to extract its exact semantics, not in the implementation. Budget half a day of reading for whoever owns the port, and expect the code itself to be unremarkable.

Bottom line: decline adoption of the package, accept the requirement. Reimplement the ordering behavior on Eloquent primitives, treat the bundle as a reference spec under MIT, and avoid inheriting a 2019 Symfony dependency into a Laravel codebase.