ESLint: Consolidate config into tools/eslint/ workspace package#77215
Merged
Conversation
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
3319803 to
e36a483
Compare
|
Size Change: 0 B Total Size: 7.76 MB ℹ️ View Unchanged
|
3 tasks
|
Flaky tests detected in 4f26feb. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/24788541183
|
tyxla
reviewed
Apr 10, 2026
| @@ -0,0 +1,47 @@ | |||
| { | |||
| "name": "@wordpress/tools-eslint", | |||
Member
There was a problem hiding this comment.
Two things come to mind here:
- If this is a package, I'd rather move it to the
packagesdirectory. - I'd rather call it
eslint-toolsand nottools-eslint, so it matches the naming pattern of the existing packages (e.g.eslint-plugin)
Member
Author
There was a problem hiding this comment.
This is just an internal workspace to isolate dependencies, it’s not a package that is supposed to be published to npm.
eslint-tools does make more sense.
Member
There was a problem hiding this comment.
It's totally fine to have a package live in packages, but not to be published to npm for various reasons. We have a few of those right now:
- connectors
- edit-site-init
- react-native-aztec
- react-native-bridge
- react-native-editor
- report-flaky-tests
- workflow
I still prefer it to live in packages because it helps with discoverability when all packages live in the same place in a monorepo.
Member
Author
There was a problem hiding this comment.
My opinion about it is different, because it's more of a monorepo "tool" that we want to manage in a workspace instead of doing it all in root. So, the tools/ directory makes more sense to me. The packages/ directory is already huge, and thus, I think the monorepo-specific tools can go into the tools/ directory.
Member
There was a problem hiding this comment.
Hmm, here's where we disagree.
In /packages we already have various packages that can be considered tools as well. But they still are in /packages, because they are practically packages in the end, and the package is a top-level unit in a monorepo. The fact that there are many packages (over 100 as of today) to me is unimportant. I'm fine with having a thousand, if we really need to.
So, since I disagree strongly here, I would suggest the following: if we end up having 3 or more packages that match your description ("monorepo-specific tools can go into the tools directory"), we can have this discussion again. But for a single package, this distinction just doesn't make sense. Note that if we have that discussion in the future, I'm very likely to disagree again 😉
Member
There was a problem hiding this comment.
The packages/ directory already has a package related to ESLint called eslint-plugin, thus adding this eslint-tools will make things confusing IMHO.
Why? Doesn't look confusing to me at all.
So, this being just an internal monorepo-related tool, it's fine for it to live outside of packages.
Not if it's a package.
The whole purpose of making it a workspace is to isolate its dependencies and clean up the root package.json as outlined in #75041.
Ah, dependency deduplication because of usage in other packages. Another good reason to keep in packages, I guess 😉
Member
Author
There was a problem hiding this comment.
Does that mean every workspace has to go to the packages/ directory?
What about these workspaces then?
Lines 256 to 264 in a3f2010
IMHO, packages directory is for published packages - a private workspace doesn’t necessarily have to be called a package, because it is not “packaged” (using npm pack) for public publishing.
Member
There was a problem hiding this comment.
I honestly never understood why we need so many workspaces. I can agree with what you're saying (a private workspace having its own packages), but why have so many?
Member
Author
There was a problem hiding this comment.
a private workspace having its own packages
I think there is some confusion in naming and understanding here. Probably because of wildcards in workspace declarations.
Each “workspace” here refers to a single directory with its own package.json, not a collection of directories with private packages. So, in this case tools/eslint/ is a single workspace, rather than tools/ being a workplace with private packages.
Likewise, each directory in packages/ is a workspace.
why have so many?
That’s a valid question but I think each serves its own purpose and thus the segregation - more of a code organisation by concern?
Member
There was a problem hiding this comment.
I agree it is confusing, and it's probably something to be revisited, but I'll unblock this, since the decisions that led us here haven't happened in this PR. Thanks for the discussion!
Member
Author
c0b4657 to
6d1c0cd
Compare
31 tasks
6d1c0cd to
c31eb62
Compare
8279ae1 to
652b985
Compare
Member
Author
|
@mirka I moved that |
mirka
approved these changes
Apr 22, 2026
Member
mirka
left a comment
There was a problem hiding this comment.
Thanks for working on this. Tests well, both for the standard linting and the suppression flow with lint-staged.
- Create tools/eslint/package.json (@wordpress/eslint-tools) as a private workspace package with all ESLint plugin dependencies - Move eslint.config.mjs/eslint.config.strict.mjs into tools/eslint/ as config.mjs and config.strict.mjs - Move bin/lint-js.js wrapper and eslint-suppressions.json into tools/eslint/ as lint-js.cjs and suppressions.json - Add thin re-export files at root for ESLint, VS Code, and lint-staged - Move ESLint plugin devDependencies from root into the workspace - Rename import-resolver.js to .cjs (CJS in "type": "module" package) - Consolidate workspaces entries to use tools/* glob
652b985 to
4f26feb
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What?
Follow up to #76654.
Closes #76506 (PR 3 — Consolidate ESLint config into workspace package).
Consolidates the root ESLint configuration into a dedicated
tools/eslint/workspace package (@wordpress/tools-eslint).Why?
As outlined in Phase 5 of the ESLint v10 upgrade plan (#76506), the root directory accumulated many ESLint-specific dependencies and config files. Moving them into a self-contained workspace package:
devDependenciesmove out of rootpackage.jsontools/eslint/package.jsonHow?
Created
tools/eslint/package.json— private workspace package with"type": "module"and package exports for./configand./config/strict.Moved config files —
eslint.config.mjs→tools/eslint/config.mjs,eslint.config.strict.mjs→tools/eslint/config.strict.mjs. Updated all relative paths (import.meta.dirname→rootDir,./packages/→../../packages/, etc.). Namedconfig.mjs(noteslint.config.mjs) to prevent ESLint from auto-discovering them as config files when linting files insidetools/eslint/.Added CJS re-exports at root —
eslint.config.cjsandeslint.config.strict.cjsdynamically import fromtools/eslint/. Using.cjspreserves git rename history for the moved.mjsfiles.Moved 15 ESLint plugin
devDependenciesfrom root intotools/eslint/package.jsonasdependencies. Root retains onlyeslint(editor integration),eslint-formatter-compact,@eslint/eslintrc(jest preset), andglob.Renamed
import-resolver.js→import-resolver.cjs— required because the package has"type": "module"and the resolver uses CommonJS.Consolidated workspaces — replaced individual
tools/api-docsentry withtools/*glob.Testing Instructions
npm install— verify clean installnpm run lint:js— should pass (0 errors, warnings are pre-existing).js/.tsfile in VS Code — verify ESLint squiggles appearvar x = 1;) in a package file — verify it's caughtgit commiton a staged.jsfile — verify lint-staged runs the strict configTesting Instructions for Keyboard
N/A — no UI changes.
Use of AI Tools
This PR was authored with assistance from Claude Code (Claude Opus 4.6). All changes were reviewed and verified manually.