Tabledrag Laravel Package

Technical Evaluation

Architecture fit. Poor. Despite living under a components/ vendor namespace, this is not a Laravel package in any conventional sense — it is a fork of Drupal 8 core's tabledrag module. Drupal 8's implementation is not a standalone library: it is a set of PHP render-array helpers (#tabledrag form property, drupal_attach_tabledrag equivalents), a jQuery/Drupal-behavior JavaScript file, and theme CSS that assume Drupal's Form API, Render API, #attached asset system, Drupal.behaviors, t() translation, and Drupal's AJAX routing. None of those primitives exist in Laravel. There is no service provider, no config file, no Blade component, no facade, no published assets — the integration surface a Laravel TPM would normally evaluate is simply absent.

Integration feasibility. Low without a rewrite. A team would effectively be porting the JavaScript and reimplementing the PHP side as Blade partials plus a Laravel controller for persistence. At that point they are consuming the package as a reference implementation, not a dependency, and should evaluate it on that basis. The jQuery dependency is the second blocker: modern Laravel front-ends standardize on Alpine/Livewire, Inertia+React/Vue, or at minimum Vite-managed ESM, and this code predates all of them.

Technical risk. High on every axis:

• Licensing — GPL-2.0 is copyleft and viral for distributed PHP applications. For a SaaS with no distribution it is often tolerable, but for any shipped product, on-prem appliance, or white-labeled deliverable it is a legal review item that frequently kills adoption outright. This alone warrants escalation to legal before any engineering time is spent.
• Maintenance — last release January 2018, one star, zero dependents, no issue activity. Assume abandoned.
• Runtime compatibility — Drupal 8-era code targets PHP 7.0–7.2. PHP 8.x deprecations and fatals are likely; there is no evidence of Laravel 8/9/10/11 support or a laravel composer type.
• Security posture — no CVE monitoring, no patch path, and an implicit client-side AJAX contract modeled on Drupal routes rather than Laravel's CSRF-protected endpoints.

Key questions for the team. (1) What exactly does the package ship — JS only, or PHP render helpers that assume a Drupal bootstrap? (2) Is there a hard requirement for nested drag-and-drop tables, or would flat reordering with a parent selector satisfy the use case? (3) Has legal signed off on GPL-2.0 for this product's distribution model? (4) Is the actual user need better served by SortableJS (MIT) plus a closure-table model? (5) Who owns the fork if we adopt it, and what is the patch SLA?

Integration Approach

Stack fit. Effectively zero for a standard Laravel stack. The package's assumptions — jQuery, Drupal behaviors, render arrays — collide with Vite, Alpine, Livewire, and Blade's component model. Treat it as incompatible until proven otherwise by a spike.

Migration path. Do not migrate to this package. If the requirement is nestable table sorting, the defensible path is:

1. kalnoy/nestedset (MIT) for hierarchical storage and tree queries, or spatie/eloquent-sortable (MIT) for flat ordering.
2. SortableJS (MIT) or vue-draggable / @dnd-kit on the client, wired to a Laravel endpoint that accepts {id, parent_id, position} and persists in a transaction.
3. Blade + Alpine for the table shell; no jQuery.

That combination is actively maintained, MIT-licensed, and has a decade of Laravel precedent behind it. The only thing components/tabledrag contributes beyond it is Drupal's specific nested-indent UI behavior, which is a few hundred lines of JS to reproduce.

Compatibility. Assume none. There is no declared Laravel or PHP constraint, no CI matrix, and no PHP 8 evidence. If a spike is run, pin it behind a throwaway branch, run PHPStan/Larastan against it, and check for each(), dynamic properties, and create_function patterns.

Sequencing. (a) Legal review of GPL-2.0 against the distribution model — gate this first, it is cheap and often terminal. (b) Two-day spike to establish whether the JS can be extracted cleanly from its Drupal assumptions. (c) If the spike succeeds, vendor the JS file directly with attribution rather than taking a Composer dependency on an abandoned package. (d) If it fails — the expected outcome — proceed with the SortableJS/nestedset path and close the ticket.

Operational Impact

Maintenance. This becomes a fork-and-own obligation from day one. There is no upstream to pull from, no release cadence, and no maintainer responsiveness. Budget for internal ownership of the JS, the PHP glue, and any security response — realistically a fraction of an engineer indefinitely, or a one-time rewrite that removes the dependency.

Support. None. Documentation is Drupal's, which describes a Drupal API that does not exist here. Onboarding material for a Laravel developer must be written from scratch. There is no vendor to escalate to.

Scaling. Backend scaling is a non-issue — the package does no server work beyond markup. The scaling risk is client-side: nested drag-and-drop over a full rendered table degrades badly beyond a few hundred rows, and the Drupal implementation re-renders the tbody on every drop. For large datasets, plan for pagination or virtualization, which this code does not offer.

Failure modes. The realistic failure set: PHP 8 fatal errors on load; jQuery version conflicts with other admin-panel assets; missing Drupal globals causing silent no-ops where the drag handles never initialize; Vite/asset-pipeline incompatibility requiring manual script tags; AJAX reorder calls hitting routes that do not exist and failing CSRF; and GPL contamination discovered late in a release cycle, forcing an emergency rip-out. The last is the most expensive because it surfaces closest to ship.

Ramp-up. Deceptively high. A Laravel engineer reading "table drag and drop" will estimate hours; the actual work requires enough Drupal fluency to translate render arrays, #attached, behaviors, and theme preprocessing. Expect one to three days before the first working prototype and materially longer to reach production quality — versus roughly the same effort to build the equivalent directly on maintained, permissively licensed tooling.

Recommendation. Do not adopt as a dependency. Capture it as a design reference for nested drag-and-drop table UX, resolve the GPL question regardless of outcome, and deliver the capability on nestedset + SortableJS. The package's only durable asset is the interaction pattern, and that is reproducible.