Eslint Release Notes

Highlights

Support for tokens and comments in SourceCode

Rule authors often work with ESLint’s SourceCode object, which represents the JavaScript source code being linted. Its getText(), getLoc(), and getRange() methods have always accepted a node, token, or comment, but the documentation didn’t describe every argument type, and the type definitions rejected some valid calls, such as passing a comment.

This release updates the documentation and type definitions to match the actual behavior. This also aligns these methods with implementations of the core SourceCodeBase interface used in language plugins. Code that calls these methods is unaffected, but TypeScript code that implements or mocks SourceCode may need its getText(), getLoc(), and getRange() signatures updated to accept tokens and comments.

Rule fixes

The following rules have been updated to work correctly in certain edge cases, including autofix behavior and the handling of supplementary Unicode characters in code:

• consistent-return
• max-lines-per-function
• new-cap
• no-eval
• no-invalid-this …

Highlights

Faster startup and linting

This release includes a set of performance improvements across ESLint’s core linting pipeline and the stylish formatter. Linting results and the public API are unchanged: the same files produce the same messages as before, just faster.

The main improvements are:

• Startup. Loading the eslint package no longer eagerly initializes the JSON Schema validator used for rule options. It’s now created the first time a rule’s options actually need to be validated, which removes about 45 modules from the initial dependency graph and reduces package load time by 20–25%.
• Rule execution. When ESLint traverses a file’s structure, it has to decide, for every piece of code, which rules are interested in it and then call those rules. This is the most frequently executed part of the linting process, and it now takes a shorter route in the most common cases. Common node selector types are handled by fast paths, and rule visitors are invoked directly whenever possible instead of through a wrapper function on every node. …

Highlights

The no-unexpected-multiline rule has been updated to check regular expression literals with d and v flags.

/* eslint no-unexpected-multiline: "error" */

// Unexpected newline between numerator and division operator
foo = bar
/regex/v.exec(baz).forEach(qux);

Copy code to clipboard

The following rules have also been updated to avoid incorrect or unexpected behavior in some edge cases:

• new-cap
• no-extra-bind
• no-unreachable
• prefer-object-has-own

Features

• 264b434 feat: add d and v flags to no-unexpected-multiline (#21305) (Gihyeon Jeong / 정기현)
• c6cc6c5 feat: check Object.prototype property names in new-cap (#21269) (crimsonjay0) …

Highlights

This patch release fixes false positives in the no-loss-of-precision rule that were introduced in v10.9.0.

Bug Fixes

• 1e641c9 fix: no-loss-of-precision false positive with trailing decimal point (#21251) (Aleksandr Shoronov)

Documentation

• ad74a8d docs: add deprecation steps for EOL package versions (#21248) (Francesco Trotta)

Chores

• 3c3ae53 chore: update ecosystem plugins (#21249) (ESLint Bot)

Highlights

New option checkConditionalExpressions in no-unmodified-loop-condition

The no-unmodified-loop-condition rule now supports a checkConditionalExpressions option. When enabled, each branch in a ternary expression is checked independently.

For example, with { "checkConditionalExpressions": true }, the rule reports the done variable as not modified in the loop:

let chunk = getInitialChunk();
let done = false;

while (chunk ? !done : false) {
    chunk = nextOrNull();
}

Copy code to clipboard

Features

• 08de88e feat: handle underflow in no-loss-of-precision (#21218) (Rithish S)
• 55db479 feat: add checkConditionalExpressions to no-unmodified-loop-condition (#21175) (sethamus)

Bug Fixes

• 2ba3025 fix: prevent unsafe no-var autofix with hoisted functions (#21213) (sethamus) …

Highlights

The following rules have been updated to ensure that they behave correctly in some edge cases:

• accessor-pairs
• getter-return
• id-denylist
• id-match
• no-unused-labels
• no-unused-vars

Bug Fixes

• 18eb0a7 fix: prevent ASI hazard in no-unused-labels autofix (#21173) (dongkyu lee)
• 151ba3f fix: false positives in getter-return and accessor-pairs (#21163) (Grit)
• 6898df9 fix: ignore meta-property names in id-denylist (#21166) (Pixel) …

Highlights

In ESLint v10.8.0, the following rules have been updated to avoid incorrect or unexpected behavior in some edge cases:

• class-methods-use-this
• prefer-object-spread
• prefer-template
• preserve-caught-error
• no-unreachable-loop

Features

• 2fee9bb feat: export ConfigObject from eslint/config (#21082) (sethamus)

Bug Fixes

• 6b8d2f7 fix: escape reserved characters in rule id in html formatter (#21129) (Francesco Trotta)
• 9091071 fix: prevent no-unreachable-loop crash when all loop types are ignored (#21116) (Pixel) …

Highlights

This release backports a fix originally released in v10.3.0 that prevents ESLint from crashing in host environments where require.cache is unavailable, such as Yarn Plug’n’Play.

Bug Fixes

• 253be16 fix: handle unavailable require cache (backport of #20812 to v9.x) (#21065) (Eric)

Documentation

• 74930ed docs: switch build to Node.js 24 (#20894) (Milos Djermanovic)
• eaec8bb docs: Add ESLint v9.x EOL notice (#20828) (Milos Djermanovic)

Chores

• 458205f chore: update @eslint/eslintrc and @eslint/js for v9.39.5 (#21077) (Francesco Trotta)
• 202117b chore: package.json update for @eslint/js release (Jenkins) …

Highlights

New option checkConstructorCallCallbacks in max-nested-callbacks

The max-nested-callbacks rule now supports a checkConstructorCallCallbacks option. When enabled, the rule also counts callback functions passed to constructor calls with new, such as new Promise((resolve) => {}), when calculating nesting depth.

For example, with { "max": 1, "checkConstructorCallCallbacks": true }, the rule reports the following code as exceeding the allowed callback nesting depth:

run(() => {
    new Promise(resolve => resolve());
});

Copy code to clipboard

New option errorClassNames in preserve-caught-error

The preserve-caught-error rule now supports an errorClassNames option. This option lets you specify additional custom error class names that must preserve the original caught error by passing it as a cause.

For example, with { "errorClassNames": ["MyError"] }, the following code is reported because the thrown MyError does not include the original error as a cause, just like built-in error types must:

try {
    doSomething();
} catch (error) {
    throw new MyError("something went wrong");
}

Copy code to clipboard

Suggestions for no-compare-neg-zero …