chore(eslint): migrate to eslint 9 and flat file configs

[hanneskuettner]

Summary

Migrate ESLint from v8 (legacy .eslintrc.js) to v9 flat config with co-located package config and make use of a single workspace eslint.config.js.

Before this PR it looks like no lint actually ran?

Changes:

• Upgrade ESLint 8 to 9 with flat config format
• Remove the @dnd-kit/eslint-config package (configs were broken/missing which might be the reason why no proper lint ran)
• Add co-located eslint.config.js files in packages that need custom rules
  • Since previously no linting took place I have started with the most relaxed configurations possible to not include additional noise in this PR and make sure the lint passes as-is. If we want we can tackle a couple of the currently ignored rules and make some improvements
• Create shared React config at config/eslint/react.config.js for reuse across react and stories package
• Move eslint plugins to package.json files where they're actually used and remove eslint from individual packages
• Use --flag v10_config_lookup_from_file for proper config resolution per package (this can be removed as soon as it stabilized in eslint v10

Structure:

• Root config: strict TypeScript rules shared by all packages
• Package configs: extend root + add package-specific relaxations as warnings
• Framework configs: pure (don't import root), composed by packages as needed (will be able to add vue, svelte etc)

[changeset-bot]

⚠️ No Changeset found

Latest commit: f02b131

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[pkg-pr-new]

Open in StackBlitz

@dnd-kit/abstract

npm i https://pkg.pr.new/clauderic/dnd-kit/@dnd-kit/abstract@1848

@dnd-kit/collision

npm i https://pkg.pr.new/clauderic/dnd-kit/@dnd-kit/collision@1848

@dnd-kit/dom

npm i https://pkg.pr.new/clauderic/dnd-kit/@dnd-kit/dom@1848

@dnd-kit/geometry

npm i https://pkg.pr.new/clauderic/dnd-kit/@dnd-kit/geometry@1848

@dnd-kit/helpers

npm i https://pkg.pr.new/clauderic/dnd-kit/@dnd-kit/helpers@1848

@dnd-kit/react

npm i https://pkg.pr.new/clauderic/dnd-kit/@dnd-kit/react@1848

@dnd-kit/state

npm i https://pkg.pr.new/clauderic/dnd-kit/@dnd-kit/state@1848

commit: f02b131

[hanneskuettner]

Haven't worked with bun a lot, is this normal that these are bumped now in the lock file? I would have expected them to use the workspace protocol and automatically get back-filled on release?

[clauderic]

Summary

This PR migrates ESLint from v8 (legacy .eslintrc.js format) to v9 flat config format. It removes the broken @dnd-kit/eslint-config internal package, introduces co-located eslint.config.js files in packages that need custom rules, and creates a shared React config at config/eslint/react.config.js.

Feedback

Suggestions

• The PR is large (1025 lines), but the bulk of this is bun.lock updates — the actual config changes are modest and well-organized.
• The PR description mentions using --flag v10_config_lookup_from_file as an experimental ESLint feature. It would be helpful to add a comment in the root package.json lint script (or in a README/contributing note) explaining that this flag is required and when it can be dropped (once ESLint v10 stabilizes this behavior), so future maintainers understand the dependency.
• The author notes linting is intentionally configured to be permissive initially to avoid noise. It would be good to track follow-up work (e.g., a separate issue or TODO) to re-evaluate the disabled/warned rules over time.

Changeset

• Status: not present — correct, no packages/*/src/ files were modified.

Overall

Clean and well-scoped migration. The flat config structure is sensible (root config → per-package configs), and the decision to start with relaxed rules to get lint running cleanly first is pragmatic. Thanks for doing this work, @hanneskuettner!

---

[claude-review]