Tabledrag Laravel Package

Product Decisions This Supports

• Admin UX roadmap for hierarchical content. Nested drag-and-drop row ordering is the interaction model behind category trees, navigation/menu builders, org-chart or department management, page builders, form/question ordering, and any CMS "weight + parent" table. If any of those are on your roadmap, this package is a signal that the problem exists — not a solution to adopt.
• Build vs. buy vs. borrow for a table-stakes admin feature. Sorting tables is rarely a differentiator; it's plumbing. The decision this package informs is whether to spend engineering weeks hand-rolling nested-set/adjacency-list drag logic or to lean on an existing library. The answer here is "neither this package" — see below.
• Licensing posture decision. GPL-2.0 is a copyleft license. If your product ships as a closed-source SaaS or commercial Laravel application, pulling this into your dependency tree is a legal review item, not just an engineering one. This is a decision the PM owns with legal, not the tech lead alone.
• Maintenance-burden budgeting. Zero dependents, one star, no release since January 2018, and a repo naming convention (components/tabledrag) that suggests a Drupal module repackaged rather than a Laravel-ecosystem package. Adopting it means you own it — permanently.
• Use-case validation. Useful internal signal: any product spec that says "and the user reorders these rows by dragging, including into nested children" should immediately trigger the standard admin-UI pattern review rather than a fresh build.

When to Consider This Package

Consider reading its source (not depending on it) if:

• You are maintaining a legacy Drupal 7/8-derived PHP application where Drupal's tabledrag behaviors, drupalSettings, and jQuery-era form APIs already exist. Here the fork may be closer to home than it looks.
• You need a reference implementation of the weight/depth/parent-indentation algorithm — how a flat table encodes a tree, how weights are recalculated and renumbered on drop, how the "tabledrag changed" hidden field is maintained. That logic is genuinely fiddly and worth studying before you write your own.
• Your stack is GPL-compatible end to end (internal tooling, an open-source product, a GPL plugin ecosystem) and the legal risk is genuinely zero.
• You need an offline, dependency-free artifact for an air-gapped environment and cannot vendor a JS library.

Look elsewhere — decisively — if any of the following is true:

• You are building on modern Laravel (9/10/11) and PHP 8.x. A 2018 Drupal 8 fork predates PHP 7.2 typed properties, let alone PHP 8. It will not be Laravel-package-shaped: expect no service provider, no config publishing, no Blade views, no Illuminate integration, and probable deprecation or fatal errors.
• Your front end is Livewire, Inertia, Vue, React, or Alpine. The drag layer here is jQuery-UI-era DOM manipulation. You would be shipping two UI paradigms at once.
• You need touch devices, keyboard-only operation, or screen-reader support. Nested drag-and-drop is one of the hardest accessibility problems in admin UI; a 2018 fork will not carry current WCAG expectations, and retrofitting them costs more than starting clean.
• You need security patching, CI, or a maintainer to escalate to. There is no release cadence, no dependents to surface bugs, and no community. Bus factor: effectively zero.
• You are a commercial/closed-source product. GPL-2.0 is the wrong license for the dependency.

Recommended substitutes: SortableJS (or sortablejs + a thin Laravel wrapper) for the drag layer, Livewire Sortable or Alpine + Sortable for reactive stacks, and a nested-set package (e.g. kalnoy/nestedset) for the persistence side. This combination is actively maintained, MIT-licensed, and covers the same feature set in an afternoon rather than a sprint.

How to Pitch It (Stakeholders)

To executives: We evaluated a package for nested drag-and-drop table sorting. My recommendation is not to adopt it. It is a single-maintainer, single-star repository with no downstream users, no release in over seven years, and a GPL-2.0 license that creates legal exposure for a closed-source product. The feature it addresses is real and worth building — but the package is not the shortcut it appears to be; adopting it converts a two-day integration into an indefinite maintenance and legal liability.

To engineering: Treat this as a specification, not a dependency. The code encodes a well-understood pattern (flat table + weight column + parent/depth indentation, with weight compaction on drop) and is useful to read for edge cases around renumbering and tree re-parenting. Do not add it to composer.json. It is a Drupal 8 fork, so expect Drupal form-API coupling, jQuery globals, PHP 7-era syntax, and no Laravel service provider. Build the feature on SortableJS (MIT) plus a nested-set package for persistence, behind our own Blade/Livewire component. Estimated effort: one to two days for a standard two-level table; three to five if true arbitrary-depth nesting and full keyboard accessibility are required. Flag the accessibility work explicitly in the estimate — it is usually the majority of the cost.

Bottom line: Low adoption risk if ignored, high total cost of ownership if adopted. Score 0.005, one star, zero dependents, and a five-year-old last release is the entire due-diligence story.