Another feature could be to drop SortableJS

[ghiscoding]

hello @6pac another potential feature to ask, or get rid of actually, is to potentially drop SortableJS and use native code. I also that this would be a breaking change and reserve it for a potential next major version. So I actually already started that work in my own repo via this open PR that I also reserve for my next major (next year in my case):
ghiscoding/slickgrid-universal#2634

Dropping SortableJS would mean 0 dependency and also decreases install size, but it would also mean that we expect the end user to be using a modern browser (no more IE for sure). Why was I looking at doing that? It's mainly because SortableJS is starting to be a bit old now and we could with simpler code and we just don't need all of what SortableJS offers (all we really need is column reorder and also Draggable Grouping to a dropzone and that's it, only these 2 things).

I did my exploration via Claude Sonnet 4.6 mostly at work since I don't have any paid AI myself (I use the free copilot at home which are usually ChatGPT 5 mini with only 200 tokens/month). So my exploration works for the most part, but I'd be curious to see if Fable does a better job!? I know 1 difference with SortableJS is that my PR has no animations whatsoever, but we could probably live with any unless it's not too many lines of code... so anyway, you could ask Claude to read my PR and see if you can re-implement it in SlickGrid (I've done that couple time with SlickGrid vs my repos and the AI is able to compare easily by looking at the git diff and then compare and implement in the target repo)

Again that could be an exploration PR reserved for the next major version since it could impact users with behaviour changes

[6pac]

sure, will add this to the list!

[6pac]

Here's the plan. Looks good to me. Any feedback before I set it going?
One issue was that you use vitest in the upstream repo. Does that replace Cypress or is it in addition to? If in addition, should we add it to this repo?
Also chose four stacked PRs (rather than one big one) that tackle one issue at a time, making it easier to bugfix later on.

Drop the SortableJS dependency from 6pac/SlickGrid

Plan drafted 2026-07-16, based on exploration of the local SlickGrid-6pac checkout (master @ 8e36af8, v5.18.5) and upstream slickgrid-universal PR #2634 (refactor/drop-sortablejs).

Context

SlickGrid's only runtime dependency is SortableJS, used for header column reordering and the draggable-grouping plugin. Upstream slickgrid-universal has already done this work in PR #2634 (still draft, held for their 2027-Q1 major). Their author's note: they first tried @formkit/drag-and-drop, but ended up dropping any external dep and going native — ~440 LOC, ~10KB smaller than the FormKit route. We want the same outcome in 6pac/SlickGrid: zero runtime dependencies.

Two findings from exploration reframe the job and make it much smaller than "remove a dependency" suggests:

1. SortableJS is never bundled. All three source references are import type only; the library is consumed as a global window.Sortable (CDN <script> in examples, window.Sortable = Sortable in the vite-demo). dist/esm/index.mjs and dist/cjs/index.js contain no sortablejs code today. So this is not a bundling or tree-shaking change.
2. The TypeScript coupling is phantom. The sortablejs package ships no type declarations and @types/sortablejs is not installed, so SortableEvent / SortableInstance / SortableOptions already resolve to implicit any (suppressed by // @ts-ignore). dist/types/plugins/slick.draggablegrouping.d.ts proves it — it emits sortableLeftInstance: any. Removing the dep breaks zero type-checking.

The real work is 5 Sortable.create() call sites across 2 files, plus a docs/examples sweep.

Decisions taken

• Placement: fold the new drag engine into src/slick.interactions.ts rather than a new file. The IIFE build strips every non-entry import (removeImportsPlugin, scripts/esbuild-plugins.mjs:5, filter: /.*/), so each browser bundle resolves deps from the global Slick object. Examples already load slick.interactions.js before slick.grid.js, and slick.grid.ts already imports Draggable/Resizable/MouseWheel from it — so this adds no new <script> tag anywhere and imposes zero migration on browser-build consumers. Cost: a focused 320-line primitives file grows to ~1000 lines, and file layout diverges from upstream.
• Tests: Cypress only. No unit test framework exists in the repo and we're not adding one.
• Shape: four stacked PRs off master (branch refactor/drop-sortablejs, matching upstream's name; feat/, bugfix/, chore/ prefixes are already used here).

Port source and adaptation map

Port these three upstream files, adapted to 6pac idioms:

Upstream	6pac target
packages/common/src/core/slickColumnReorderDrag.ts (~650 LOC; exports setupColumnReorderDrag, setupDropzonePillDrag, each returning { destroy })	fold into src/slick.interactions.ts
packages/common/src/interfaces/slickColumnReorderDrag.interfaces.ts (ColumnReorderDragOption, DropzonePillDragOption)	src/models/interactions.interface.ts, exported via src/models/index.ts
test/cypress/support/drag.ts (HTML5 DataTransfer commands)	merge into the existing cypress/support/drag.ts

Idiom translations:

• getOffset() from @slickgrid-universal/utils → Utils.offset(), already at src/slick.core.ts:1004 and already used by the current reorder code.
• this.triggerEvent(...) → this.trigger(...).
• ESM-only import → the dual-mode idiom: import { setupColumnReorderDrag as setupColumnReorderDrag_ } from './slick.interactions.js' (join the existing import at src/slick.grid.ts:98) plus const setupColumnReorderDrag = IIFE_ONLY ? Slick.setupColumnReorderDrag : setupColumnReorderDrag_; (join the block at src/slick.grid.ts:116-119).
• Register new exports in the existing Utils.extend(Slick, { Draggable, MouseWheel, Resizable }) block at src/slick.interactions.ts:314-320.
• Upstream's vitest specs → Cypress e2e.

PR 1 — Cypress characterization tests (no src/ changes)

Header column reordering — the single largest feature being rewritten — has zero automated coverage today. This PR is load-bearing: it must pass identically before and after the refactor, and it is the only safety net.

• Extend cypress/support/drag.ts with HTML5 DataTransfer commands ported from upstream: a shared new DataTransfer() dispatched through dragstart → dragenter → dragover → drop → dragend, with clientX/clientY/pageX/pageY attached via Object.defineProperty. The existing mouse-based helpers (dragStart, dragCell, dragOutside, dragEnd) stay — the row-move specs depend on them.
• New spec for header reorder covering: plain reorder; frozen columns (the left/right header boundary must stay uncrossable — there is no group option today, so cross-side drags are impossible and that must be preserved); unorderable columns (unorderableColumnCssClass — must not move but must still resize, which is what preventOnFilter: false buys today); onColumnsReordered firing with correct impactedColumns/previousColumnOrder; scroll position preserved on frozen grids (the scrollToX(prevScrollLeft) workaround at src/slick.grid.ts:1994); hidden columns keeping position.
• The two existing grouping specs (cypress/e2e/example-draggable-grouping.cy.ts:98, example-draggable-header-grouping.cy.ts:86) use @4tw/cypress-drag-drop's .drag() and must keep passing throughout.

PR 2 — native column reorder engine + grid wiring

• Add setupColumnReorderDrag(options: ColumnReorderDragOption): InteractionBase to src/slick.interactions.ts and register it on the Slick namespace. Reuse Utils.offset(); reuse the existing InteractionBase { destroy: () => void } return shape from src/models/interactions.interface.ts.
• Add ColumnReorderDragOption to src/models/interactions.interface.ts (src/models/*.ts is excluded from IIFE builds at scripts/builds.mjs:107, which is fine — type-only).
• src/slick.grid.ts:
  • Delete the sortablejs import type + @ts-ignore (lines 1-2).
  • Replace fields sortableSideLeftInstance / sortableSideRightInstance with protected _columnReorderDrag?: InteractionBase;.
  • Guard (lines 680-681): replace throw new Error('SlickGrid requires Sortable.js module to be loaded') with the repo's existing precedent at src/slick.grid.ts:2039-2040 — if (typeof setupColumnReorderDrag === 'undefined') throw new Error('Slick.setupColumnReorderDrag is undefined, make sure to import "slick.interactions.js"').
  • Rewrite setupColumnReorder() (lines 1929-2006) following upstream's version. Adopt upstream's columnMap reconciliation — it correctly handles hidden and reorderable columns, which 6pac's Column already declares (src/models/column.interface.ts:135 and :162) but whose current this.columns[this.getColumnIndex(id)] mapping does not honour. This is a latent bug fix, not just a port.
  • destroy() (lines 1101-1104): this._columnReorderDrag?.destroy().
• The toArray() / data-id read-back contract disappears. onDragEnd(reorderedIds: string[]) hands the order over directly. Worth noting the current code silently depends on SortableJS's default dataIdAttr: 'data-id' happening to match the dataset.id set at src/slick.grid.ts:1828 — slick.grid.ts never sets dataIdAttr itself. The new engine reads data-id explicitly.
• Keep the hand-rolled frozen-column auto-scroll (currently setInterval(scrollColumnsRight/Left, 100) at ±10px, lines 1959-1970). Upstream's engine takes container / viewportScrollContainerX / hasFrozenColumns options for exactly this.
• SortableJS stays installed — slick.draggablegrouping.ts still needs it. Examples untouched.
• Check origin/bugfix/frozen-header-reorder before starting — frozen-header reorder is the hairiest area here and that branch suggests it is actively buggy on master.

PR 3 — draggable grouping

The harder half: SortableJS's cross-list clone semantics (group: {name:'shared', pull:'clone', put:false} on the headers → group:'shared' on the dropzone) have no native equivalent and must be rebuilt from dropzoneSelector + onDrop + dataTransfer.setData('text/plain', columnId).

• Add setupDropzonePillDrag(options: DropzonePillDragOption): InteractionBase to src/slick.interactions.ts + register.
• src/plugins/slick.draggablegrouping.ts:
  • Delete the sortablejs import type (lines 1-2).
  • getSetupColumnReorder() (lines 158-264): replace both Sortable.create calls (251-252) with setupColumnReorderDrag, wiring the dropzone via dropzoneSelector / onDrop. It currently resolves targets by global document.querySelector('.<uid> .slick-header-columns-left'); the passed-in headers refs can be used instead.
  • setupColumnDropbox() (lines 299-342): replace Sortable.create with setupDropzonePillDrag; onAdd → onColumnDrop, onUpdate → onPillDragEnd; swap Sortable.utils.clone() for cloneNode(true). The evt.clone.style.opacity = '.5'; el.parentNode?.removeChild(el) dance exists only to undo SortableJS's own insert — it should disappear.
  • addDragOverDropzoneListeners() (289-297) exists because "Sortable doesn't have onOver, we need to implement it ourselves" (comment at line 333). The new engine has onColumnDragEnter / onColumnDragLeave, so this hand-rolled set can likely fold in.
  • destroySortableInstances() (280-287): rename; the ?.el liveness probe (271, 281, 284) has no equivalent — just call destroy().
  • Breaking API change: getSetupColumnReorder() returns { sortableLeftInstance, sortableRightInstance } (lines 260-263) — a genuinely public return value. Change it to return the new instance(s) or nothing, and document it.

PR 4 — remove the dependency + sweep

• package.json:63-65 — delete the dependencies block entirely. The package now has zero runtime dependencies.
• Delete src/global.d.ts:1 (import type { Sortable }) and :66 (var Sortable); eslint.config.mjs:48 (Sortable: true); vite-demo/package.json:13 and vite-demo/src/main.js:3,11; and the file examples/sortable-cdn-fallback.js.
• Scripted sweep, deletions only: drop the two <script> tags (jsdelivr CDN + sortable-cdn-fallback.js) from 97 of 101 examples/*.html and 5 tests/*.html. Nothing needs adding — that is the payoff of folding into slick.interactions.ts.
• scripts/builds.mjs:153 — remove the now-stale // packages: 'external', // check SortableJS.
• README.md:21, 24, 102 — "the project now only has 1 small dependency requirement which is SortableJS" becomes a zero-dependency selling point. Leave the historical CHANGELOG.md entries alone; add a new breaking-change entry + wiki migration note.

Behaviour deltas to accept (upstream hit these too)

• No drag animation — SortableJS's animation: 50 has no native equivalent.
• Minor visual differences during drag; ghost via native setDragImage(), with a cloned absolutely-positioned ghost (opacity 0.8) as fallback.
• Port upstream's browser workarounds rather than reinventing them — they took 22 commits to stabilise: Firefox-on-Linux falls back to mousedown, touch uses touchstart + a manual ghost, and the ghost is hidden during elementFromPoint calls to avoid self-detection.

Verification

• npm run build:prod (runs lint first) and npm run build:types.
• npm run serve:demo + npm run cypress — the PR 1 specs must pass unchanged at every stage; that is the whole point of landing them first.
• Manual matrix, since Cypress can't cover the browser quirks upstream fixed: Chrome / Firefox / Safari × mouse + touch, on example-frozen-columns.html, example-draggable-grouping.html, example-draggable-header-grouping.html.
• Confirm dist/browser/slick.interactions.js now contains the drag engine, and that no dist/** output references sortablejs.
• After PR 4: npm ls sortablejs returns empty; grepping examples/ for "sortable" leaves only CSS class names (.slick-sortable-placeholder, .slick-droppable-sortitem-hover) — keep those class names to avoid a second breaking change for consumers' custom CSS.

Risks

• Frozen columns + auto-scroll is the most fragile area, and origin/bugfix/frozen-header-reorder implies it is already broken on master.
• PR 3's cross-list clone drag is the hardest port; SortableJS's group semantics are doing real work there.
• No unit tests exist in the repo, so Cypress plus the manual browser matrix is the entire safety net.
• Upstream's PR is still a draft targeting their next major — their code may yet change. Worth a note in the PR that we're porting a moving target, and worth cross-linking the two PRs.

[ghiscoding]

Vitest is for unit tests and Cypress is for E2E tests, I use both in my repo to cover all areas

[ghiscoding]

I also read quickly the draft and I agree with "fold into src/slick.interactions.ts" and I was actually thinking of doing the same in my PR as well.

[6pac]

Just a note - your work account should have Opus and Fable as options. I use Opus on Max for most coding (eg. the typescript convertion/jquery removal), and it's fine, but I knew these Slickgrid features were really complex so I went all out for them with Fable on Ultracode.

[ghiscoding]

no we don't have that option because at work they pay for Copilot not for Claude directly. The Copilot gives a mix of ChatGPT and Claude models and we never have access to latest models because it's Copilot for GitHub Enterprise.

[6pac]

@ghiscoding Just one other thing - I'm generally not that fussed about bundle size. That's of course not saying you should throw caution to the wind and go with anything - I'm always keen to slim things if possible - but I think we have a different use case to a lot of the web.

On commercial websites like Shopify sites, the visitor is often first-time and highly sensitive to page load time. If the page isn't snappy, you lose traffic. It's that simple. That's why there is a very understnadable obsession with bundle sizes and CDNs.

However I (and I think you) design custom database-driven websites for business use, that people log into every day and use as part of their workflow. That means that firstly, they don't care about a small change in load time, and secondly almost everything they use as part of that website is already cached locally - which is even faster than downloading the files, no matter how small.
So while it's commendable to try and reduce payloads, I think for the Slickgrid use case, this is much less of an imperative than for the web at large. Slickgrid is a complex, high powered control. If you want small and fast - use something else!!

[ghiscoding]

Sure a data grid is mostly used for business projects which also don't care as much for bundle size, but still if you look at the poll in #853 that I've done after releasing v5, a few users answered dropping jQuery and also provide ESM builds and those answers are mostly towards smaller bundle size, people do care and I care. Sure size isn't the most important thing for businesses, but if your project size double then yes they might start to look at alternatives. A very common problem with AI is that it often wants to rewrite everything from scratch without looking at what utils or common code that we already have available, we often have to supervised it to make sure it reuse more things instead of creating new and unnecessary utils (without proper supervision, AI often produces spaghetti code, more code on top of more code and it's often mentioned in articles).

But anyway, the size was the easiest way to explain it, but in my project it's also because SortableJS never provided an ESM only build and also never provided TypeScript types on their own. We can get types via the external @types/sortablejs package (maintained by the community, not by the SortableJS author), and SortableJS also does provide some form of ESM bundle but it's not a true ESM only bundle and it totally breaks with the external @types/sortablejs types.... so there's that but also like I said above the SortableJS code is starting to be old and was written when IE was king, but now that IE is officially dead, then the code could become a lot more simpler with native code and less hacky stuff in their codebase.

in summary SortableJS is starting to be old (we don't need IE code anymore), it could be modernized, it still doesn't provide a proper ESM build, and also never provided types by itself (because it's not written in TypeScript)