The Technical Steering Committee (TSC) has finalized the features for ESLint v10.0.0. This post outlines our high-level plans for v10.0.0. For more details, and to keep up to date with everything that is planned for v10.0.0, visit our project board.Development planSimilar to v9.0.0, we will develop v10.0.0 in phases to ensure stability and gather community feedback:Alpha. The alpha release will include the most significant breaking changes that we expect will cause the most disruption for existing users. This early release will help us gather feedback and validate our approach.Beta. The beta release will include the remaining features and smaller breaking changes that will impact fewer users.After the beta has been validated through community testing, we will publish one or more release candidates as we continue to fix bugs and address compatibility issues.Significant changes in v10.0.0-alphaThe following changes are planned for the alpha release and represent significant breaking chan

HighlightsallowTypeImports option in no-restricted-importsThe no-restricted-imports rule now supports the allowTypeImports option.When set to true, this will allow type-only imports in TypeScript files while still disallowing regular imports.For example, the following rule setting permits only type-only imports from the node:assert module:/* eslint no-restricted-imports: ["error", { name: "node:assert", allowTypeImports: true, }]*/import assert from "node:assert"; // ❌ Incorrectimport type { AssertionError } from "node:assert"; // ✅ Correct12345678910Copy code to clipboard This aligns the no-restricted-imports rule with the corresponding typescript-eslint rule, and continues ESLint’s ongoing efforts to extend TypeScript Syntax support in core rules.Improved heuristic for --concurrency=autoAfter the introduction of multithreaded linting in ESLint v9.34.0, some users running ESLint with the --cache flag reported slower performance when using --concurrency=auto compared to leaving the --c

HighlightsThis release fixes several edge cases in the recently added preserve-caught-error rule. In some cases, this can result in reporting more linting errors.All config objects exported from the @eslint/js package are now deeply frozen.Features47afcf6 feat: correct preserve-caught-error edge cases (#20109) (Francesco Trotta)Bug Fixes75b74d8 fix: add missing rule option types (#20127) (ntnyq)1c0d850 fix: update eslint-all.js to use Object.freeze for rules object (#20116) (루밀LuMir)7d61b7f fix: add missing scope types to Scope.type (#20110) (Pixel998)7a670c3 fix: correct rule option typings in rules.d.ts (#20084) (Pixel998)Documentationb73ab12 docs: update examples to use defineConfig (#20131) (sethamus)31d9392 docs: fix typos (#20118) (Pixel998)c7f861b docs: Update README (GitHub Actions Bot)6b0c08b docs: Update README (GitHub Actions Bot)91f97c5 docs: Update README (GitHub Actions Bot)Chores12411e8 chore: upgrade @eslint/[email protected] (#20139) (Milos Djermanovic)488cba6 chore: package.j

HighlightsNew Rule preserve-caught-errorOne new rule has been added to the core: preserve-caught-error.This rule enforces the use of the cause property when throwing a new error inside a catch block.An example of incorrect code for this rule:/* eslint preserve-caught-error: "error" */try { // ...} catch (error) { throw new Error("Something went wrong");}1234567Copy code to clipboard An example of correct code for this rule:/* eslint preserve-caught-error: "error" */try { // ...} catch (error) { throw new Error("Something went wrong", { cause: error });}1234567Copy code to clipboard Other notable changesThe no-empty-function and no-empty-static-block rules now provide suggestions to add an /* empty */ comment when the function or class static block is intentionally empty.The no-empty rule now allows empty switch statements with a comment inside the body.Features42761fa feat: implement suggestions for no-empty-function (#20057) (jaymarvelz)102f444 feat: implement suggestions for no-empty

ESLint v9.34.0 introduces multithread linting, concluding a feature that’s been in the making for over ten years.By spawning several worker threads, ESLint can now process multiple files at the same time, dramatically reducing lint times for large projects.On machines with multiple CPU cores and fast storage, this change can make a noticeable difference — especially when you’re linting hundreds or thousands of files. Our early testers have seen a speedup of around 1.30x as a starting point, while one even reported a 3.01x improvement.HistoryThe idea of parallelizing the linting process has been around for well over a decade, long before Node.js offered built-in worker threads. Early discussions wrestled with fundamental questions: which tools should be used for parallelization, how far should the scope extend, and what architectural changes would be required to make it possible. There were also concerns about the potential downsides — the extra maintenance burden, the risk of slowing d

HighlightsESLint v9.34.0 introduces multithread linting — the ability to process multiple files simultaneously using multiple threads. This feature can significantly reduce lint times for large projects.To enable it, run ESLint with the --concurrency flag:npx eslint --concurrency=auto1Copy code to clipboard Read everything in the announcement.Features0bb777a feat: multithread linting (#19794) (Francesco Trotta)43a5f9e feat: add eslint-plugin-regexp to eslint-config-eslint base config (#19951) (Pixel998)Bug Fixes9b89903 fix: default value of accessor-pairs option in rule.d.ts file (#20024) (Tanuj Kanti)6c07420 fix: fix spurious failure in neostandard integration test (#20023) (Kirk Waiblinger)676f4ac fix: allow scientific notation with trailing zeros matching exponent (#20002) (Sweta Tanwar)Documentation0b4a590 docs: make rulesdir deprecation clearer (#20018) (Domenico Gemoli)327c672 docs: Update README (GitHub Actions Bot)bf26229 docs: Fix typo in core-concepts/index.md (#20009) (Tobia

HighlightsExplicit resource management support in one-varThe one-var rule now handles variables declared with the using and await using syntax, for example:async function test() { using foo = 1, bar = 2; await using baz = 3, qux = 4;}1234Copy code to clipboard using and await using declarations are part of the explicit resource management feature introduced in ES2026 JavaScript.Global object access detection in no-restricted-globalsThe no-restricted-globals rule can now catch usages of restricted globals when they’re accessed as properties of the global object, such as window.Promise. This enhanced behavior is controlled by three new options:checkGlobalObjectAccess: A boolean that, when enabled, reports restricted globals accessed via the global object.globalObjects: A list of identifiers treated as global object references. globalThis, self, and window are always included.globals: A list of restricted global names, each optionally paired with a custom message to report when used.Featu

HighlightsRules updated for explicit resource managementThe following core rules were updated to support the new using and await using declarations from the explicit resource management feature:curly: Now allows using and await using as the only statement in a block, similar to how let and const are handled, to avoid parser errors.no-unused-vars: Treats variables declared with using/await using as used, since their Symbol.dispose is implicitly called at the end of their scope. Also adds an option to ignore unused using declarations.prefer-destructuring: No longer requires destructuring for using/await using declarations, as this would be a parse error.require-await and no-await-in-loop: Both rules now recognize await using as an await expression for their checks and reporting.These changes ensure ESLint core rules are compatible with the upcoming JavaScript explicit resource management syntax, providing accurate linting and avoiding false positives or parse errors.Rules updated for Typ

HighlightsExplicit resource management support in core rulesFour core rules have been updated to better support explicit resource management, a new feature in ES2026 JavaScript, including support for using and await using syntax.The init-declarations rule no longer reports on initializing using and await using variables when the option is "never", because these variables must be initialized. For example:async function foobar() { await using quux = getSomething();}123Copy code to clipboard The no-const-assign rule now reports on modifying using and await using variables. For example:if (foo) { using a = getSomething(); a = somethingElse;}1234Copy code to clipboard The no-loop-func rule no longer reports on references to using and await using variables, because these variables are constant. For example:for (using i of foo) { var a = function() { return i; }; // OK, all references are referring to block scoped variables in the loop. a();}1234Copy code to clipboard The no-undef-init rule n

HighlightsSeparate default and named type import declarations in no-duplicate-importsThe no-duplicate-imports rule now allows both a default type import and named type imports from the same module in separate declarations.import type A from "some-module";import type { B, C } from "some-module";12Copy code to clipboard This change accommodates a TypeScript limitation: a default type import cannot be combined with named type imports in a single declaration.Bug Fixese91bb87 fix: allow separate default and named type imports (#19899) (xbinaryx)Documentationab7c625 docs: Update README (GitHub Actions Bot)dae1e5b docs: update jsdoc’s link (#19896) (JamesVanWaza)Choresb035f74 chore: upgrade to @eslint/[email protected] (#19906) (Francesco Trotta)b3dbc16 chore: package.json update for @eslint/js release (Jenkins)