GO — Healthy across all four use cases

• Last commit 5mo ago
• 5 active contributors
• MIT licensed
• CI configured
• Tests present
• ⚠ Slowing — last commit 5mo ago
• ⚠ Single-maintainer risk — top contributor 87% of recent commits

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

Shopify/draggable is a 16.2kB JavaScript library that abstracts native browser drag-and-drop events into a unified API with support for native drag, mouse, touch, and force-touch events. It provides four core modules—Draggable (base), Sortable, Droppable, and Swappable—allowing developers to build custom drag-and-drop experiences with hooks into the full event lifecycle. The library creates mirrors, manages sensor events, and handles cross-browser compatibility without imposing sorting behavior itself. Monorepo structure: core library in the root with source organized into modules (Draggable, Sortable, Droppable, Swappable), build outputs in /build (ESM, UMD, CommonJS), comprehensive examples under /examples (its own npm package with Babel, PostCSS, BrowserSync), config files for TypeScript (/config/typescript) and linting (.eslintrc.js, .prettierrc), and GitHub Actions workflows for CI and release automation.

Frontend developers (React, vanilla JS, Vue, etc.) building e-commerce dashboards, admin panels, or SaaS products that need drag-and-drop UX—particularly those at Shopify who use it in apps but also open-source users seeking an event-driven alternative to jQuery UI draggable or react-beautiful-dnd.

Production-ready but in maintenance mode: the original Shopify authors explicitly stated 'no longer maintained by its original authors' (see README), though the repo has CI/CD via GitHub Actions workflows (.github/workflows/) and a published npm package. Maintenance has been passed to community collaborators. The codebase is stable ES6+ (targeted at modern browsers) but active development is low.

Moderate risk: the project is actively seeking new maintainers (quoted in README), indicating potential abandonment if no one steps up. The repo has 225KB of JavaScript and 80KB of TypeScript, split across multiple modules, which increases surface area for bugs. Heavy reliance on sensor-based event detection (mouse, touch, native drag) makes cross-browser testing critical. No explicit security audit or test coverage metrics visible in the provided file list.

The repo is in maintenance/triage mode: the README actively recruits new maintainers, indicating recent ownership transition. GitHub Actions workflows (.github/workflows/) show CI (ci.yml), changelog management (changelog.yml), CLA checks (cla.yml), and release automation (release.yml), suggesting automated QA and publishing. No specific breaking changes or active features are evident from the file list, but changesets (.changeset/) indicate versioning work.

Clone and install: git clone https://github.com/Shopify/draggable.git && cd draggable && npm install (or yarn install). Then start the examples dev server: cd examples && npm install && npm start. For the main library development, run linting and tests (exact test command not visible, but lint commands exist: npm run lint:js, npm run lint:scss).

Daily commands: For library development: npm install && npm run lint:js && npm run prettier:js (code quality). For the examples app: cd examples && npm install && NODE_OPTIONS=--openssl-legacy-provider npm start (dev server on localhost with hot reload via BrowserSync). Production build: NODE_OPTIONS=--openssl-legacy-provider npm run build:prod.

• README.md — Contains the project mission, maintenance status, and architectural overview—essential for understanding why this library exists and its current governance.
• CONTRIBUTING.md — Documents contribution guidelines, development workflow, and testing standards that all collaborators must follow.
• babel.config.js — Core transpilation configuration for the entire JavaScript codebase; changes here affect all builds and compatibility.
• .eslintrc.js — Linting rules enforced across the codebase; establishes code quality and consistency standards.
• examples/package.json — Defines dependencies and build scripts for the examples sandbox; critical for local development setup.
• .github/workflows/ci.yml — CI/CD pipeline definition; controls testing, building, and release automation for every commit.
• LICENSE.md — MIT license terms; establishes legal usage rights for all code in this repository.

• Draggable Core (Vanilla JavaScript, DOM APIs, event system) — Main library class that manages drag state, binds events, and coordinates plugins.
  • Failure mode: If events fail to bind or state becomes inconsistent, drags may not start or elements may stick to cursor.
• Babel/Transpiler (Babel, babel.config.js) — Converts source code to ES5 for cross-browser compatibility.
  • Failure mode: Transpilation errors or misconfiguration result in syntax errors in older browsers or broken builds.
• Examples Application (HTML, SCSS, JavaScript, Webpack/Gulp (examples build system)) — Interactive demos showcasing draggable.js in action; serves as integration tests and documentation.
  • Failure mode: Broken examples indicate regressions in the core library or missing dependencies.
• CI/CD Pipeline (GitHub Actions (ci.yml, release.yml), Node.js, npm) — Automatically lints, tests, builds, and releases new versions to npm.
  • Failure mode: Pipeline failure blocks merges; release workflow failure prevents new versions from

Add a New Example Demo

1. Create a new component directory under examples/src/components with HTML and SCSS files following the pattern of existing components (e.g., Block, Button). (examples/src/components/NewComponent/NewComponent.html)
2. Define component styles in a matching SCSS file, importing shared props from the component's props.scss. (examples/src/components/NewComponent/NewComponent.scss)
3. If the component needs JavaScript behavior, create an index.js file that initializes draggable instances or handles interactions. (examples/src/components/NewComponent/index.js)
4. Register the component in the examples build system (typically in examples/src/index.js or the main page template). (examples/src/index.js)

Fix a Code Quality Issue

1. Run ESLint locally to identify violations: check .eslintrc.js for active rules and run the lint script defined in package.json. (.eslintrc.js)
2. Format code with Prettier to fix formatting issues automatically, respecting the configuration in .prettierrc. (.prettierrc)
3. Verify changes pass CI by examining the ci.yml workflow to understand what linters and tests run automatically. (.github/workflows/ci.yml)

Release a New Version

1. Add a changeset file describing the change by running the changeset CLI and selecting the version bump type (major, minor, patch). (.changeset)
2. Commit the changeset file—the release workflow in GitHub Actions will automatically consume it and update CHANGELOG.md. (.github/workflows/release.yml)
3. The release workflow will publish the new version to npm automatically once the PR is merged. (.github/workflows/release.yml)

Contribute Code Following Repository Standards

1. Read CONTRIBUTING.md to understand the development workflow, PR process, and coding conventions. (CONTRIBUTING.md)
2. Ensure your Node.js version matches .nvmrc to avoid environment-related issues. (.nvmrc)
3. Run linting and formatting checks locally using the configurations in .eslintrc.js, .prettierrc, and babel.config.js before pushing. (.eslintrc.js)

• Babel — Transpiles ES6+ JavaScript to ES5 for broad browser compatibility; critical for a library targeting diverse environments.
• ESLint + Prettier — Enforces consistent code style and catches errors early; essential for a large open-source project with many contributors.
• Changesets — Automates semantic versioning and changelog generation, reducing manual release friction and improving release velocity.
• GitHub Actions — Provides free CI/CD infrastructure integrated with Git; runs linting, testing, and automated releases on every commit.

• Library maintenance passed to community collaborators instead of remaining Shopify-owned.

  • Why: Reduces organizational burden and allows the community to guide the library's direction.
  • Consequence: Maintenance velocity depends on volunteer collaborator availability; may slow down issue resolution and feature development.

• Examples built as a separate npm package (examples/package.json) rather than embedded in main package.

  • Why: Keeps the core library lean and allows examples to have independent dependencies.
  • Consequence: Requires dual package management and separate build/test processes for core vs. examples.

• Broad browser compatibility via Babel transpilation to ES5.

  • Why: Maximizes usability across legacy and modern browsers.
  • Consequence: Bundle size and transpilation overhead; must maintain backward compatibility in API design.

• Does not provide framework-specific integrations (e.g., React, Vue wrappers)—users integrate the vanilla library themselves.
• Does not include touch/mobile event handling abstractions—relies on native browser APIs.
• Does not provide state management or persistence—purely a DOM manipulation and event system.
• Does not handle accessibility (ARIA attributes, keyboard navigation)—user responsibility.
• Is not a UI component library—only the drag/drop mechanics and event system.

(1) Node.js version pinning: .nvmrc specifies a strict Node version; mismatches may cause crypto issues (hence the widespread NODE_OPTIONS=--openssl-legacy-provider env var in all build commands—indicates compatibility with older Node). (2) OpenSSL legacy mode required: almost every npm script prefixes NODE_OPTIONS=--openssl-legacy-provider, suggesting the build pipeline needs legacy crypto (likely due to old dependencies like webpack/Gulp versions). (3) Dual source trees: core library in / and examples app in /examples/ are separate npm workspaces with separate package.json, linting, and Babel configs—changes to library don't auto-rebuild examples. (4) Sensor-based event detection is global: Draggable uses sensors to intercept mouse/touch/drag events at document level; multiple Draggable instances may conflict if not carefully isolated. (5) Mirror DOM creation: the library creates a 'mirror' element for visual feedback; browser style isolation (CSS) may not apply, requiring inline styles or careful CSS namespacing.

• Sensor abstraction (event delegation) — Draggable detects drags via pluggable 'sensors' (MouseSensor, TouchSensor, NativeDragSensor) rather than hardcoding handlers; understanding how sensors intercept and normalize events is key to extending Draggable or debugging cross-browser issues
• Mirror element and DOM ghosting — Draggable creates a visual 'mirror' of the dragged element that follows the cursor; this requires careful DOM cloning, z-index management, and style isolation to avoid layout thrashing and CSS cascade conflicts
• Drag event lifecycle and hooking — Draggable emits events at each drag phase (dragstart, dragmove, dragstop, etc.); understanding the full lifecycle (setup → mount → over → drop → unmount) is essential for custom behavior (e.g., conditional dropping, animated transitions)
• Touch vs. pointer events and fallback detection — The library must handle native drag (MouseEvent + DragEvent), touch (TouchEvent), and modern Pointer events; sensor selection and fallback chaining is non-trivial (e.g., iOS Safari only supports native drag, not pointer events)
• Event propagation and stopPropagation() in drag handlers — Draggable must prevent default browser drag behavior (text selection, link navigation) while allowing event bubbling for custom handlers; misunderstanding event.preventDefault() vs. event.stopPropagation() leads to bugs where drags interfere with parent listeners
• Reflow and repaint optimization (transform vs. top/left) — The mirror element moves many times per second during drag; using CSS transform instead of top/left prevents layout recalculation and keeps animations at 60 FPS; Draggable likely optimizes this internally, but understanding the principle is crucial for custom mirror styles
• Event-driven state management (pub/sub pattern) — Draggable uses events (not direct method calls) for communication between modules (Sortable, Droppable emit events that other listeners consume); this decouples modules but requires careful listener cleanup to avoid memory leaks

• react-beautiful-dnd/react-beautiful-dnd — Direct competitor for React apps; similar drag-drop library but opinion-driven (beautiful animations, Scrum-board bias) vs. Draggable's flexibility
• SortableJS/Sortable — Alternative vanilla JS drag-and-drop library; smaller footprint, narrower use case (list sorting), no mirror/event abstraction like Draggable
• lodash/lodash — Commonly used utility library in Shopify tech stack; Draggable likely depends on some lodash utilities (debounce, throttle) for sensor event handling
• Shopify/polaris — Shopify's design system and React component library; uses Draggable (or similar) internally for DnD in admin UI components
• floating-ui/floating-ui — Complementary positioning library; often paired with Draggable to handle mirror/tooltip placement during drag operations

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive TypeScript type definitions and tests for core draggable classes

The repo has config/typescript/rollup-plugin-includepaths.d.ts but no visible comprehensive type definitions for the main Draggable, Sortable, Swappable, etc. classes. With TypeScript configuration present and doc/typescript.md existing, adding proper .d.ts files for all exported classes and thorough type tests would improve DX and catch type-related bugs early.

• [ ] Review src/ directory structure and identify all exported classes/functions
• [ ] Create comprehensive .d.ts files in src/ for Draggable, Sortable, Swappable, and plugin classes
• [ ] Add type tests in tests/ directory to verify type definitions match implementations
• [ ] Update tsconfig.json if needed to include generated .d.ts files in npm package
• [ ] Document TypeScript usage examples in doc/typescript.md with real-world patterns

Implement GitHub Actions workflow for automated accessibility (a11y) testing

The repo has .github/workflows/ with CI, changelog, CLA, and release workflows, but no automated a11y testing. Given that draggable affects keyboard navigation and ARIA attributes (critical for drag-drop UX), adding an axe-core or pa11y workflow would catch regressions in accessibility compliance.

• [ ] Create .github/workflows/a11y.yml that runs on PRs and push to main
• [ ] Install axe-core and @axe-core/playwright or pa11y in examples/package.json devDependencies
• [ ] Write accessibility test scripts in examples/ that validate draggable components for WCAG 2.1 compliance
• [ ] Configure workflow to fail on accessibility violations and report results in PR comments
• [ ] Document accessibility testing requirements in CONTRIBUTING.md

Add unit test coverage for examples/src/components with snapshot testing

The examples/ directory contains many components (Block, Button, GridOverlay, etc.) with SCSS and HTML but no visible test files. Adding Jest/Vitest snapshot tests and component unit tests would prevent visual regressions and ensure example components remain functional as the draggable library evolves.

• [ ] Set up Jest or Vitest in examples/ with @testing-library/dom configuration
• [ ] Create tests/ directory mirroring examples/src/components/ structure
• [ ] Add snapshot tests for each component (Block.test.js, Button.test.js, etc.)
• [ ] Add unit tests for component interactions, especially drag-drop behavior on actual examples
• [ ] Integrate test runner into examples/package.json scripts and CI pipeline

• Add TypeScript definitions for all event payloads in Sortable/Droppable/Swappable modules—the repo has TypeScript config (/config/typescript) and doc/typescript.md but type coverage is incomplete; write .d.ts files for all public APIs
• Create integration tests for cross-sensor behavior (e.g., mouse drag → touch drag fallback, native drag + custom sensor conflict)—file list shows CI workflow but no explicit test directory; add tests/ folder with jest/mocha specs for Draggable and each module
• Document the sensor abstraction layer and how to write custom sensors—README mentions 'extend drag detection by adding sensors' but no example sensor in /examples/src; add a CustomSensor example component showing touch vs. pointer API usage

The Shopify Draggable codebase presents moderate security concerns. The most critical issues are the use of deprecated OpenSSL legacy provider flags (which disable security validations) and an unverified Git dependency. The project is noted as no longer actively maintained by Shopify, which compounds the risk. Key recommendations: (1) Remove NODE_OPTIONS=--openssl-legacy-provider and update build tools, (2) Replace the unverified 'threads' Git dependency with a published/verified version, (3) Conduct a full npm audit and update outdated dependencies, (4) Ensure lock files are version controlled, and (5) Establish clear security policies and update documentation. The project would benefit from finding active maintainers as noted in the README.

• High · Deprecated OpenSSL Provider Usage — examples/package.json - scripts section (views, scripts, styles, start, build, build:prod, prepublish). Multiple npm scripts use 'NODE_OPTIONS=--openssl-legacy-provider' which bypasses OpenSSL 3.0 security restrictions. This flag was introduced as a temporary workaround for compatibility issues and should not be used in production environments. It disables important security validations. Fix: Update dependencies to versions compatible with OpenSSL 3.0. Remove the --openssl-legacy-provider flag and upgrade @babel/core, @babel/register, and other build tools to their latest versions that support modern OpenSSL.
• High · Unverified Git Dependency — examples/package.json - dependencies.threads. The 'threads' package is installed from an unverified GitHub branch (beefchimi/threads.git#v1.0.0-beta8) instead of a published npm package. This bypasses npm's security checks and could introduce supply chain risks. Fix: Either publish the forked version to npm and use the official package, or verify the fork's trustworthiness. Ensure the custom fork is regularly maintained and audit its code. Consider switching to the official 'threads' package if possible.
• Medium · Incomplete Dependency List in package.json — examples/package.json - devDependencies section. The devDependencies section appears truncated in the provided file (ends with 'eslint-plugin' without completion). This makes it impossible to fully audit all dependencies for known vulnerabilities. Fix: Provide complete package.json content. Run 'npm audit' to identify vulnerable dependencies. Keep all dependencies updated to their latest secure versions.
• Medium · No lock file version control visible — examples/ directory. While package.json is present, no package-lock.json or yarn.lock file is shown in the file structure. Without lock files, dependency versions can vary across environments, potentially introducing inconsistent security patches. Fix: Ensure package-lock.json (for npm) or yarn.lock (for yarn) is committed to version control. This guarantees consistent dependency versions across all environments.
• Medium · Development Tools in Production — examples/package.json and root babel.config.js, .eslintrc.js. The codebase mixes development and example configurations with potential to be deployed. Tools like eslint, prettier, and babel are configured but security best practices for production builds are not visible. Fix: Ensure development dependencies are excluded from production builds. Use NODE_ENV=production in build scripts and implement proper build artifact verification.
• Low · Missing SECURITY.md — Root directory. No SECURITY.md or security policy file is visible in the root directory. This makes it difficult for security researchers to report vulnerabilities responsibly. Fix: Create a SECURITY.md file with instructions for responsible vulnerability disclosure and security reporting procedures.
• Low · Outdated ESLint Configuration — examples/package.json - devDependencies.eslint. ESLint v7.10.0 is specified, which is significantly outdated (current stable is v8+). Newer versions include additional security-focused rules and fixes. Fix: Update eslint to the latest stable version (v8 or v9) and associated plugins to benefit from improved security rule coverage.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/Shopify/draggable shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live Shopify/draggable repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/Shopify/draggable.

What it runs against: a local clone of Shopify/draggable — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in Shopify/draggable | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 188 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of Shopify/draggable. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/Shopify/draggable.git
#   cd draggable
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of Shopify/draggable and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "Shopify/draggable(\\.git)?\\b" \\
  && ok "origin remote is Shopify/draggable" \\
  || miss "origin remote is not Shopify/draggable (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"
test -f "CONTRIBUTING.md" \\
  && ok "CONTRIBUTING.md" \\
  || miss "missing critical file: CONTRIBUTING.md"
test -f "babel.config.js" \\
  && ok "babel.config.js" \\
  || miss "missing critical file: babel.config.js"
test -f ".eslintrc.js" \\
  && ok ".eslintrc.js" \\
  || miss "missing critical file: .eslintrc.js"
test -f "examples/package.json" \\
  && ok "examples/package.json" \\
  || miss "missing critical file: examples/package.json"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 188 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~158d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/Shopify/draggable"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.