Eslint Release Notes

Expanding language support: CSS and HTML

Following the release of JSON and Markdown support in 2024, we continued our mission to make ESLint a truly language-agnostic linter. In February, we released official CSS support via the @eslint/css plugin, allowing users to lint their stylesheets with the same familiar configuration system.

In May, we were excited to announce that html-eslint had joined the ESLint ecosystem as a language plugin, bringing robust HTML linting to the project. These additions mean that ESLint can now officially be used to lint the “big three” of the web: JavaScript, CSS, and HTML.

ESLint’s new CSS and HTML support were highlighted in three different talks at Google I/O as well as on the Chrome blog.

ESLint continues to grow

ESLint’s usage continued its relentless climb in 2025. We started the year with 42,717,190 weekly npm downloads and ended with a staggering 70,713,031 weekly downloads—a 65% increase in just twelve months. By the end of the year, ESLint had reached 2,964,923,725 total downloads for 2025 alone, a testament to the critical role it plays in the modern web development ecosystem.

Note: The dips downloads at the start and end of the year are regular seasonal declines that all packages see during the holidays.

Downloads for the v9.x release line continue to grow as the ecosystem upgrades from v8.x. By the end of 2025 and beginning of 2026, weekly downloads for the v9.x release line topped 36 million, more than half of our weekly downloads. The v8.x release line is still popular with over 26 million weekly downloads.

Integrating with AI

As AI became an integral part of the development workflow in 2025, we worked to ensure that ESLint remains a key part of that experience. In November, GitHub announced that ESLint is now integrated with Copilot code review in public preview. This integration allows Copilot to surface ESLint violations directly during the code review process, helping developers catch issues before they are merged.

We also embraced the Model Context Protocol (MCP) by releasing the @eslint/mcp package. This MCP server allows AI models, such as those used in VS Code’s Copilot, to interact directly with ESLint. By providing the AI with direct access to linting results and the ability to run ESLint on demand, we’re helping these tools provide more accurate and context-aware suggestions for your codebase.

Performance and workflow improvements

One of the most significant technical achievements of 2025 was the introduction of multithreaded linting in v9.34.0. This feature, which had been in discussion for over a decade, allows ESLint to utilize multiple CPU cores to lint files in parallel. Large projects have seen performance improvements ranging from 30% to over 300%, depending on the hardware and project structure.

We also introduced bulk suppressions in April. This feature allows teams to adopt stricter linting rules incrementally by marking existing violations for later fixing without cluttering the source code with comments. It has become a key tool for large-scale migrations and maintaining code quality in professional environments.

Updates to support the latest ECMAScript features

Keeping pace with the JavaScript language remains a core priority. In 2025, we added support for the following new JavaScript features:

• ES2026 Explicit Resource Management (using declarations)
• ES2025 Regex modifiers (completed rollout)
• ES2025 Global variables (Float16Array and Iterator)

These updates ensure that ESLint remains an up-to-date tool for modern JavaScript development.

The road to ESLint v10.0.0

The end of 2025 was focused on the next major milestone: ESLint v10.0.0. This release represents a significant cleanup of the project, including:

• Dropping support for Node.js < 20.19.0, allowing us to take advantage of modern Node.js features like native ESM support in require().
• Full removal of the legacy eslintrc configuration system, finalizing the transition to flat config that began years ago.
• Improving JSX reference tracking, making scope analysis more accurate for modern React and SolidJS applications.

We released the first alpha in November, followed by a beta in December, and we are currently in the release candidate phase as we head into 2026.

Financials review

The next few sections dig into the project financials. All of this information is gathered from the Open Collective transaction list with the exception of Tidelift payments (which are retrieved from Tidelift directly). Our fiscal 2025 runs from January 1, 2025 at midnight UTC to December 31, 2025 at 11:59 p.m. UTC.

Income review

During 2025, ESLint received $204,451.97 USD from all of our income sources. You can see the breakdown of our income sources in the following table.

We are pleased to see continued growth in our primary sponsorship channels via Open Collective and GitHub Sponsors. However, we saw a continued decline in Tidelift revenue and a significant drop in website ad revenue as we moved entirely to Ethical Ads.

Thanks.dev revenue actually increased to $11,337.61. This is a clerical issue because we forgot to cash out before the end of 2025 so $9,875.87 was received after the transaction deadline for our financials. Because we didn’t use this money to pay for expenses in 2025, we didn’t include it in the table.

Top sponsors

In 2025, we received generous donations from many companies, led by Automattic and Airbnb ($24,000 each), Meta Open Source ($20,000), and AG Grid ($20,000).

Expenses review

In 2025, we spent $262,150.09 USD on the ESLint project as a whole vs. $204,451.97 of income for a net loss of -$57,698.12. This is slightly better than our $59,705.24 loss in 2024, but it still reflects our active investment of our reserves into the project’s future.

Our Maintenance and Development costs continued to rise as we welcome four new team members, maintained three language plugins, tackled the core rewrite and the preparation for v10.0.0. We also significantly increased our investment in the Contributor Pool, which compensates outside contributors for high-impact work. We were able to offset some of these increases with lower costs for triage and community management compared to 2024.

Supporting our dependencies and ecosystem

As part of our commitment to the financial health of the JavaScript ecosystem, we continued to donate to the projects we depend on. In 2025, we increased our total donations to $16,500.00.

Looking forward to 2026

With ESLint v10.0.0 just around the corner, 2026 is shaping up to be another landmark year. Once v10.0.0 is stable, our primary focus will shift towards:

• Completing the Core Rewrite: Moving the remainder of the legacy core logic into the new language-agnostic architecture and making the core asynchronous.
• Expanding Language Plugins: Further improving CSS, JSON, and Markdown support, and exploring official plugins for other common web formats.
• Performance Optimization: Continuing to refine multithreaded linting and looking for further opportunities to reduce linting times.
• Cross-file Linting: Allow ESLint to follow dependencies through the files that it’s linting for more accurate results.

We are incredibly grateful to our community and sponsors for their continued support. Your contributions allow us to maintain ESLint as a high-quality, free, and open-source tool for millions of developers. We look forward to another year of growing and improving together!

Original source Report a problem

We just pushed ESLint v10.0.0-rc.0, which is a major release upgrade of ESLint. This release adds some new features and fixes several bugs found in the previous release. This release also has some breaking changes, so please read the following closely.

Highlights

This version of ESLint is not ready for production use and is provided to gather feedback from the community before releasing the final version. Please let us know if you have any problems or feedback by creating issues on our GitHub repo.

Note that this prerelease version of ESLint has a separate documentation section.

Enhancements to RuleTester

Since its earliest days, ESLint has provided the RuleTester API to help plugin authors test their rules against custom test cases and configurations. This release introduces several enhancements to RuleTester to enforce more robust test definitions and improve debugging.

requireData assertion option

A new assertion option, requireData, is now available. When set to true, RuleTester will require invalid test cases to include a data object whenever a messageId references a message with placeholders. This helps ensure that tests remain consistent with rule messages that rely on placeholder substitution.

For example, consider a hypothetical rule no-trivial-sum that reports on expressions such as 1 + 2 and defines a message with placeholders:

trivialSum: "Trivial sum found. Replace {{actualExpression}} with {{sum}}."

If an invalid test case includes messageId: "trivialSum" but omits data:

assertionOptions: { requireData: true }, invalid: [ { code: "const a = 1 + 2;", errors: [ { messageId: "trivialSum" } ] } ]

RuleTester will now throw an assertion error indicating that the data property is missing.

To resolve this, include the placeholder values in the error object:

{ code: "const a = 1 + 2;", errors: [ { messageId: "trivialSum", data: { actualExpression: "1 + 2", sum: 3 } } ] }

Improved location reporting for failing tests

RuleTester now decorates stack traces with information that makes it easier to locate failing test cases in your source code. For example, if the no-trivial-sum rule fails to report an error for 1 + 2, the test case in the previous section will fail and the test output will include stack trace lines like:

roughly at RuleTester.run.invalid[0] (/my-project/test/no-trivial-sum.js:10)
roughly at RuleTester.run.invalid (/my-project/test/no-trivial-sum.js:7)

The first line indicates:
• invalid[0]: the index of the failing test case in the invalid array
• /my-project/test/no-trivial-sum.js:10: the file and line number where that test case is defined. Many IDE terminals, including Visual Studio Code’s, recognize this format and allow you to click directly to the relevant line.

The second line points to the start of the entire invalid array.

Note that these line numbers may not always be included, depending on how your tests are structured. When the lines cannot be determined precisely, the failing test index (e.g., 0) and the printed code snippet are still available to locate the test case.

countThis option in max-params rule

The max-params rule now supports the new countThis option, which supersedes the deprecated countVoidThis. With the setting countThis: "never", the rule will now ignore any this annotation in a function’s argument list when counting the number of parameters in a TypeScript function. For example:

function doSomething(this: SomeType, first: string, second: number) {
  // ...
}

will be considered a function taking only 2 parameters.

Installing

Since this is a pre-release version, you will not automatically be upgraded by npm. You must specify the next tag when installing:

npm i eslint@next --save-dev

You can also specify the version directly:

npm i [email protected] --save-dev

Migration Guide

As there are a lot of changes, we’ve created a migration guide describing the breaking changes in great detail along with the steps you should take to address them. We expect that most users should be able to upgrade without any build changes, but the migration guide should be a useful resource if you encounter problems.

Breaking Changes

• feat!: estimate rule-tester failure location ( #20420 ) (ST-DDT)

Features

• feat: rule tester add assertion option requireData ( #20409 ) (fnx)
• feat: output RuleTester test case failure index ( #19976 ) (ST-DDT)
• feat: add countThis option to max-params ( #20236 ) (Gerkin)

Bug Fixes

• fix: update eslint ( #20427 ) (renovate[bot])
• fix: error location should not modify error message in RuleTester ( #20421 ) (Milos Djermanovic)
• fix: ensure filename is passed as third argument to verifyAndFix() ( #20405 ) (루밀LuMir)
• fix: remove ecmaVersion and sourceType from ParserOptions type ( #20415 ) (Pixel998)
• fix: remove TDZ scope type ( #20231 ) (jaymarvelz)
• fix: correct Scope typings ( #20404 ) (sethamus)
• fix: update verify and verifyAndFix types ( #20384 ) (Francesco Trotta)

Documentation

• docs: Update README (GitHub Actions Bot)
• docs: [no-await-in-loop] Expand inapplicability ( #20363 ) (Niklas Hambüchen)
• docs: Update README (GitHub Actions Bot)
• docs: update config syntax in no-lone-blocks ( #20413 ) (Pixel998)
• docs: remove redundant sourceType: "module" from rule examples ( #20412 ) (Pixel998)
• docs: correct .mts glob pattern in files with extensions example ( #20403 ) (Ali Essalihi)

Chores

• chore: package.json update for @eslint/js release (Jenkins)
• refactor: remove raw parser option from JS language ( #20416 ) (Pixel998)
• chore: remove category from type test fixtures ( #20417 ) (Pixel998)
• chore: remove category from formatter test fixtures ( #20418 ) (Pixel998)
• chore: add JSX language tag validation to check-rule-examples ( #20414 ) (Pixel998)
• chore: pin dependencies ( #20397 ) (renovate[bot])
• test: replace deprecated rules in linter tests ( #20406 ) (루밀LuMir)
• test: enable strict mode in type tests ( #20398 ) (루밀LuMir)
• refactor: remove lib/linter/rules.js ( #20399 ) (Francesco Trotta)
• chore: updates for v9.39.2 release (Jenkins)

Original source Report a problem

We just pushed ESLint v9.39.2, which is a patch release upgrade of ESLint. This release fixes several bugs found in the previous release.

Highlights

This release prints a warning message when an /* eslint-env / configuration comment is found in the code being linted. The warning includes the filename and line number of the comment, along with instructions on how to replace it. The purpose of this warning is to allow for a smoother migration, since starting with ESLint v10.0.0, / eslint-env */ comments are reported as errors by the linter, as explained in the migration guide.

Bug Fixes

• fix: warn when eslint-env configuration comments are found (#20381) (sethamus)

Build Related

• build: add .scss files entry to knip (#20391) (Milos Djermanovic)

Chores

• chore: upgrade to @eslint/[email protected] (#20394) (Francesco Trotta)
• chore: package.json update for @eslint/js release (Jenkins)
• ci: add v9.x-dev branch (#20382) (Milos Djermanovic)

Original source Report a problem

Highlights

This version of ESLint is not ready for production use and is provided to gather feedback from the community before releasing the final version. Please let us know if you have any problems or feedback by creating issues on our GitHub repo.

Most of the highlights of this release are breaking changes, and are discussed further in the migration guide. There are summaries of the significant changes below. (Less significant changes are included in the migration guide.)

This prerelease version of ESLint has a separate documentation section.

RuleTester assertion options

The RuleTester#run() method now supports assertion options, specifically requireMessage and requireLocation, to let developers enforce stricter requirements in rule tests. These options enforce that every invalid test case explicitly checks violation messages and/or locations, ensuring that a test fails if it doesn’t meet the requirements.

• requireMessage
  • Ensures every test case includes a message check.
  • Accepts:
    • true: Must use an array of objects for errors, rather than a numeric count shorthand, to check the problems reported by a rule. Each object must include a message or messageId property as usual to check the message of a reported problem.
    • "message": Must check using message only.
    • "messageId": Must check using messageId only.
  • Purpose: Prevents tests from passing without verifying the actual message.
• requireLocation
  • Ensures every test case includes a location check.
  • Accepts:
    • true
  • Requires line and column in each object of the errors array.
  • endLine and endColumn are optional if the actual report doesn’t include them.
  • Purpose: Guarantees that tests validate the location of an error.

Example Usage:

ruleTester.run("my-rule", rule, {
  valid: [
    { code: "var foo = true;" }
  ],
  invalid: [
    {
      code: "var invalidVariable = true;",
      errors: [
        { message: "Unexpected invalid variable.", line: 1, column: 5 }
      ]
    }
  ],
  assertionOptions: {
    requireMessage: true,
    requireLocation: true
  }
});

Here, the test must include both a message check and location check for each error.

JSX references are now tracked

ESLint v10.0.0 now tracks JSX references, enabling correct scope analysis of JSX elements.

Previously, JSX identifiers weren’t tracked as references, which could lead to incorrect results in rules relying on scope information. For example:

import { Card } from "./card.jsx";
export function createCard(name) {
  return <Card name={name} />;
}

Prior to v10.0.0:

• False positives: could be reported as “defined but never used” (no-unused-vars).
• False negatives: Removing the import might not trigger an “undefined variable” error (no-undef).

Starting with v10.0.0, is treated as a normal reference to the variable in scope. This eliminates confusing false positives/negatives, aligns JSX handling with developer expectations, and improves the linting experience in projects using JSX.

If your codebase includes JSX, you may start seeing new linting reports. To fix them, update your code or adjust rule configurations as needed.

color property in formatter context

When the --color or --no-color option is specified on the command line, ESLint sets an additional color property on the context object passed to a formatter (the second argument of the format() method). This property is true for --color and false for --no-color. Custom formatters can use this value to determine whether to apply color styling, based on the assumption that the terminal supports or does not support colors as indicated by the option.

For the default “stylish” formatter, the --color or --no-color option now takes precedence over other rules checked by Node.js (such as the environment variables FORCE_COLOR, NODE_DISABLE_COLORS, etc.) when deciding whether to apply colorization.

Installing

Since this is a pre-release version, you will not automatically be upgraded by npm. You must specify the next tag when installing:

npm i eslint@next --save-dev

You can also specify the version directly:

npm i [email protected] --save-dev

Migration Guide

As there are a lot of changes, we’ve created a migration guide describing the breaking changes in great detail along with the steps you should take to address them. We expect that most users should be able to upgrade without any build changes, but the migration guide should be a useful resource if you encounter problems.

Breaking Changes

• a176319 feat!: replace chalk with styleText and add color to ResultsMeta (#20227) (루밀LuMir)
• c7046e6 feat!: enable JSX reference tracking (#20152) (Pixel998)

Features

• f148a5e feat: add error assertion options (#20247) (ST-DDT)

Bug Fixes

• ba6ebfa fix: correct typings for loadESLint() and shouldUseFlatConfig() (#20393) (루밀LuMir)
• e7673ae fix: correct RuleTester typings (#20105) (Pixel998)
• 53e9522 fix: strict removed formatters check (#20241) (ntnyq)
• b017f09 fix: correct no-restricted-import messages (#20374) (Francesco Trotta)

Documentation

• 264b981 docs: Update README (GitHub Actions Bot)
• 5a4324f docs: clarify "local" option of no-unused-vars (#20385) (Milos Djermanovic)
• e593aa0 docs: improve clarity, grammar, and wording in documentation site README (#20370) (Aditya)
• 3f5062e docs: Add messages property to rule meta documentation (#20361) (Sabya Sachi)
• 9e5a5c2 docs: remove Examples headings from rule docs (#20364) (Milos Djermanovic)
• 194f488 docs: Update README (GitHub Actions Bot)

Build Related

• a126a2a build: add .scss files entry to knip (#20389) (Francesco Trotta)

Chores

• 54bf0a3 ci: create package manager test (#20392) (루밀LuMir)
• 3115021 refactor: simplify JSDoc comment detection logic (#20360) (Pixel998)
• 4345b17 chore: update @eslint-community/regexpp to 4.12.2 (#20366) (루밀LuMir)
• 772c9ee chore: update dependency @eslint/eslintrc to ^3.3.3 (#20359) (renovate[bot])

Original source Report a problem

Highlights

This version of ESLint is not ready for production use and is provided to gather feedback from the community before releasing the final version. Please let us know if you having any problems or feedback by creating issues on our GitHub repo.

Most of the highlights of this release are breaking changes, and are discussed further in the migration guide. There are summaries of the significant changes below. (Less significant changes are included in the migration guide.)

This prerelease version of ESLint has a separate documentation section.

Removed deprecated SourceCode methods

The following SourceCode methods are no longer available:

• getTokenOrCommentBefore() - Use getTokenBefore() with the { includeComments: true } option instead
• getTokenOrCommentAfter() - Use getTokenAfter() With the { includeComments: true } option instead
• isSpaceBetweenTokens() - Use isSpaceBetween() instead
• getJSDocComment() - No replacement

Users of plugins that haven’t updated their code yet can use the @eslint/compat utility in the meantime.

Installing

Since this is a pre-release version, you will not automatically be upgraded by npm. You must specify the next tag when installing:

npm i eslint@next --save-dev

You can also specify the version directly:

npm i [email protected] --save-dev

Migration Guide

As there are a lot of changes, we’ve created a migration guide describing the breaking changes in great detail along with the steps you should take to address them. We expect that most users should be able to upgrade without any build changes, but the migration guide should be a useful resource if you encounter problems.

Breaking Changes

• fa31a60 feat!: add name to configs (#20015) (Kirk Waiblinger)
• 3383e7e fix!: remove deprecated SourceCode methods (#20137) (Pixel998)
• 501abd0 feat!: update dependency minimatch to v10 (#20246) (renovate[bot])
• ca4d3b4 fix!: stricter rule tester assertions for valid test cases (#20125) (唯然)

Features

• 09e6654 feat: update error loc of require-yield and no-useless-constructor (#20267) (Tanuj Kanti)

Documentation

• 0f5a94a docs: [class-methods-use-this] explain purpose of rule (#20008) (Kirk Waiblinger)
• df5566f docs: add Options section to all rule docs (#20296) (sethamus)
• adf7a2b docs: no-unsafe-finally note for generator functions (#20330) (Tom Pereira)
• ef7028c docs: Update README (GitHub Actions Bot)
• fbae5d1 docs: consistently use “v10.0.0” in migration guide (#20328) (Pixel998)
• 778aa2d docs: ignoring default file patterns (#20312) (Tanuj Kanti)

Chores

• 0b14059 chore: package.json update for @eslint/js release (Jenkins)
• d6e7bf3 ci: bump actions/checkout from 5 to 6 (#20350) (dependabot[bot])
• 139d456 chore: require mandatory headers in rule docs (#20347) (Milos Djermanovic)
• 3b0289c chore: remove unused .eslintignore and test fixtures (#20316) (Pixel998)
• a463e7b chore: update dependency js-yaml to v4 [security] (#20319) (renovate[bot])
• ebfe905 chore: remove redundant rules from eslint-config-eslint (#20327) (Milos Djermanovic)
• 88dfdb2 test: add regression tests for message placeholder interpolation (#20318) (fnx)
• 6ed0f75 chore: skip type checking in eslint-config-eslint (#20323) (Francesco Trotta)

Original source Report a problem

Highlights

This version of ESLint is not ready for production use and is provided to gather feedback from the community before releasing the final version. Please let us know if you having any problems or feedback by creating issues on our GitHub repo.

Most of the highlights of this release are breaking changes, and are discussed further in the migration guide. There are summaries of the significant changes below. (Less significant changes are included in the migration guide.)

This prerelease version of ESLint has a separate documentation section.

Node.js < v20.19.0, v21, v23 no longer supported

As of this post, Node.js v22.x is the LTS release, and as such we are dropping support for all versions of Node.js prior to v20.19.0 as well as v21.x and v23.x.

ESLint v10.0.0 supports the following versions of Node.js:

• Node.js v20.19.0 and above
• Node.js v22.13.0 and above
• Node.js v24 and above

New configuration file lookup algorithm

ESLint v10.0.0 locates eslint.config.* by starting from the directory of each linted file rather than the current working directory as it was the case with ESLint v9.x. The new behavior allows for using multiple configuration files in the same run and can be particularly useful in monorepo setups.

In ESLint v9.x, this config lookup behavior could be enabled with the v10_config_lookup_from_file feature flag. In ESLint v10.0.0, this behavior is now the default and the v10_config_lookup_from_file flag has been removed.

Removed eslintrc functionality

As announced in Flat config rollout plans, the eslintrc config system has been completely removed in ESLint v10.0.0. Specifically, this means:

1. The ESLINT_USE_FLAT_CONFIG environment variable is no longer honored.
2. The CLI no longer supports eslintrc-specific arguments (--no-eslintrc, --env, --resolve-plugins-relative-to, --rulesdir, --ignore-path).
3. .eslintrc.* and .eslintignore files will no longer be honored.
4. /* eslint-env */ comments are reported as errors.
5. The loadESLint() function now always returns the ESLint class.
6. The Linter constructor configType argument can only be "flat" and will throw an error if "eslintrc" is passed.
7. The following Linter eslintrc-specific methods are removed:
   • defineParser()
   • defineRule()
   • defineRules()
   • getRules()
8. The following changes to the /use-at-your-own-risk entrypoint:
   • LegacyESLint is removed
   • FileEnumerator is removed
   • shouldUseFlatConfig() function will always return true

Jiti < v2.2.0 no longer supported

ESLint v10.0.0 drops support for jiti versions prior to 2.2.0 when loading TypeScript configuration files due to known issues that can cause compatibility problems when configurations load certain plugins.

Updated eslint:recommended

The eslint:recommended configuration is updated to include new rules that we feel are important.

Removed deprecated rule context members

The following rule context members are no longer available:

• context.getCwd() - Use context.cwd instead
• context.getFilename() - Use context.filename instead
• context.getPhysicalFilename() - Use context.physicalFilename instead
• context.getSourceCode() - Use context.sourceCode instead
• context.parserOptions - Use context.languageOptions or context.languageOptions.parserOptions instead
• context.parserPath - No replacement

Users of plugins that haven’t updated their code yet can use the @eslint/compat utility in the meantime.

Removed deprecated LintMessage#nodeType and TestCaseError#type properties

In ESLint v10.0.0, the deprecated nodeType property on LintMessage objects has been removed. Correspondingly, RuleTester no longer accepts the deprecated type property in errors of invalid test cases.

Program AST node range spans entire source text

Starting with ESLint v10.0.0, Program AST node’s range spans the entire source text. Previously, leading and trailing comments/whitespace were not included in the range.

The default parser (espree) has already been updated. Custom parsers are expected to be updated accordingly.

New requirements for ScopeManager implementations

Starting with ESLint v10.0.0, custom ScopeManager implementations must automatically resolve references to global variables declared in the code, including var and function declarations, and provide an instance method addGlobals(names: string[]) that creates variables with the given names in the global scope and resolves references to them.

The default ScopeManager implementation (eslint-scope) has already been updated. Custom ScopeManager implementations are expected to be updated accordingly.

Installing

Since this is a pre-release version, you will not automatically be upgraded by npm. You must specify the next tag when installing:

npm i eslint@next --save-dev

You can also specify the version directly:

npm i [email protected] --save-dev

Migration Guide

As there are a lot of changes, we’ve created a migration guide describing the breaking changes in great detail along with the steps you should take to address them. We expect that most users should be able to upgrade without any build changes, but the migration guide should be a useful resource if you encounter problems.

Breaking Changes

• 96512a6 fix!: Remove deprecated rule context methods (#20086) (Nicholas C. Zakas)
• c69fdac feat!: remove eslintrc support (#20037) (Francesco Trotta)
• 208b5cc feat!: Use ScopeManager#addGlobals() (#20132) (Milos Djermanovic)
• a2ee188 fix!: add uniqueItems: true in no-invalid-regexp option (#20155) (Tanuj Kanti)
• a89059d feat!: Program range span entire source text (#20133) (Pixel998)
• 39a6424 fix!: assert ‘text’ is a string across all RuleFixer methods (#20082) (Pixel998)
• f28fbf8 fix!: Deprecate "always" and "as-needed" options of the radix rule (#20223) (Milos Djermanovic)
• aa3fb2b fix!: tighten func-names schema (#20119) (Pixel998)
• f6c0ed0 feat!: report eslint-env comments as errors (#20128) (Francesco Trotta)
• 4bf739f fix!: remove deprecated LintMessage#nodeType and TestCaseError#type (#20096) (Pixel998)
• 523c076 feat!: drop support for jiti < 2.2.0 (#20016) (michael faith)
• 454a292 feat!: update eslint:recommended configuration (#20210) (Pixel998)
• 4f880ee feat!: remove v10_* and inactive unstable_* flags (#20225) (sethamus)
• f18115c feat!: no-shadow-restricted-names report globalThis by default (#20027) (sethamus)
• c6358c3 feat!: Require Node.js ^20.19.0 || ^22.13.0 || >=24 (#20160) (Milos Djermanovic)

Documentation

• 4b5dbcd docs: reorder v10 migration guide (#20315) (Milos Djermanovic)
• 5d84a73 docs: Update README (GitHub Actions Bot)
• 37c8863 docs: fix incorrect anchor link in v10 migration guide (#20299) (Pixel998)
• 077ff02 docs: add migrate-to-10.0.0 doc (#20143) (唯然)
• 3822e1b docs: Update README (GitHub Actions Bot)

Chores

• 1e2cad5 chore: package.json update for @eslint/js release (Jenkins)
• 9da2679 chore: update @eslint/* dependencies (#20321) (Milos Djermanovic)
• 0439794 refactor: use types from @eslint/core (#20235) (jaymarvelz)
• cb51ec2 test: cleanup SourceCode#traverse tests (#20289) (Milos Djermanovic)
• 897a347 chore: remove restriction for type in rule tests (#20305) (Pixel998)
• d972098 chore: ignore prettier updates in renovate to keep in sync with trunk (#20304) (Pixel998)
• a086359 chore: remove redundant fast-glob dev-dependency (#20301) (루밀LuMir)
• 564b302 chore: install prettier as a dev dependency (#20302) (michael faith)
• 8257b57 refactor: correct regex for eslint-plugin/report-message-format (#20300) (루밀LuMir)
• e251671 refactor: extract assertions in RuleTester (#20135) (唯然)
• 2e7f25e chore: add legacy-peer-deps to .npmrc (#20281) (Milos Djermanovic)
• 39c638a chore: update eslint-config-eslint dependencies for v10 prereleases (#20278) (Milos Djermanovic)
• 8533b3f chore: update dependency @eslint/json to ^0.14.0 (#20288) (renovate[bot])
• 796ddf6 chore: update dependency @eslint/js to ^9.39.1 (#20285) (renovate[bot])

Original source Report a problem

We just pushed ESLint v9.39.1, which is a patch release upgrade of ESLint. This release fixes several bugs found in the previous release.

Highlights

This patch release fixes an issue introduced in ESLint v9.39.0 where visitors of all rules are invoked with a second argument. This change broke third-party rules that expect visitor functions to receive only a single argument, notably @typescript-eslint/unified-signatures. To ensure compatibility, ESLint v9.39.1 restores the previous behavior of invoking visitors for JavaScript/TypeScript with only the target node as the argument.

Bug Fixes

• 650753e fix: Only pass node to JS lang visitor methods (#20283) (Nicholas C. Zakas)

Documentation

• 51b51f4 docs: add a section on when to use extends vs cascading (#20268) (Tanuj Kanti)
• b44d426 docs: Update README (GitHub Actions Bot)

Chores

• 92db329 chore: update @eslint/js version to 9.39.1 (#20284) (Francesco Trotta)
• c7ebefc chore: package.json update for @eslint/js release (Jenkins)
• 61778f6 chore: update eslint-config-eslint dependency @eslint/js to ^9.39.0 (#20275) (renovate[bot])
• d9ca2fc ci: Add rangeStrategy to eslint group in renovate config (#20266) (唯然)
• 009e507 test: fix version tests for ESLint v10 (#20274) (Milos Djermanovic)

Original source Report a problem

We just pushed ESLint v9.39.0, which is a minor release upgrade of ESLint. This release adds some new features and fixes several bugs found in the previous release.

Highlights

More precise problem locations

ESLint v9.39.0 introduces improvements that narrow the highlighted locations for certain rule violations. By reducing unnecessary highlighting, these changes cut down on visual noise and make issues in code easier to spot and fix.

Here’s what’s new:

• complexity: In v9.38.0, this rule was updated to highlight only a function’s header instead of the entire function. With v9.39.0, the same refinement now applies to class static blocks: only the header is highlighted, not the whole block.
• for-direction: Now highlights only the header portion of a for loop, instead of the full statement.
• no-dupe-args: Now highlights just the argument list in a function definition, not the whole function.
• no-dupe-class-members: Now highlights only the identifiers of duplicated members, rather than their full definitions.

Unified rule performance report

When the TIMING environment variable is set and ESLint runs in multithread mode with the --concurrency option, the output now includes a single, unified performance report. This consolidated report aggregates timing data from all threads, replacing the previous behavior of printing multiple separate reports.

Example:

$ TIMING=1 npx eslint --concurrency=2
Rule                                | Time (ms) | Relative
:-----------------------------------|----------:|--------:
jsdoc/valid-types                   |   484.199 |     5.1%
n/no-extraneous-require             |   431.187 |     4.5%
jsdoc/check-access                  |   375.205 |     3.9%
jsdoc/check-values                  |   323.224 |     3.4%
jsdoc/check-types                   |   308.546 |     3.2%
jsdoc/check-tag-names               |   305.308 |     3.2%
n/no-unsupported-features/es-syntax |   275.097 |     2.9%
expect-type/expect                  |   257.434 |     2.7%
jsdoc/check-alignment               |   255.678 |     2.7%
jsdoc/require-property-type         |   250.951 |     2.6%

Features

• cc57d87 feat: update error loc to key in no-dupe-class-members (#20259) (Tanuj Kanti)
• 126552f feat: update error location in for-direction and no-dupe-args (#20258) (Tanuj Kanti)
• 167d097 feat: update complexity rule to highlight only static block header (#20245) (jaymarvelz)

Bug Fixes

• 15f5c7c fix: forward traversal step.args to visitors (#20253) (jaymarvelz)
• 5a1a534 fix: allow JSDoc comments in object-shorthand rule (#20167) (Nitin Kumar)
• e86b813 fix: Use more types from @eslint/core (#20257) (Nicholas C. Zakas)
• 927272d fix: correct Scope typings (#20198) (jaymarvelz)
• 37f76d9 fix: use AST.Program type for Program node (#20244) (Francesco Trotta)
• ae07f0b fix: unify timing report for concurrent linting (#20188) (jaymarvelz)
• b165d47 fix: correct Rule typings (#20199) (jaymarvelz)
• fb97cda fix: improve error message for missing fix function in suggestions (#20218) (jaymarvelz)

Documentation

• d3e81e3 docs: Always recommend to include a files property (#20158) (Percy Ma)
• 0f0385f docs: use consistent naming recommendation (#20250) (Alex M. Spieslechner)
• a3b1456 docs: Update README (GitHub Actions Bot)
• cf5f2dd docs: fix correct tag of no-useless-constructor (#20255) (Tanuj Kanti)
• 10b995c docs: add TS options and examples for nofunc in no-use-before-define (#20249) (Tanuj Kanti)
• 2584187 docs: remove repetitive word in comment (#20242) (reddaisyy)
• 637216b docs: update CLI flags migration instructions (#20238) (jaymarvelz)
• e7cda3b docs: Update README (GitHub Actions Bot)
• 7b9446f docs: handle empty flags sections on the feature flags page (#20222) (sethamus)

Chores

• dfe3c1b chore: update @eslint/js version to 9.39.0 (#20270) (Francesco Trotta)
• 2375a6d chore: package.json update for @eslint/js release (Jenkins)
• a1f4e52 chore: update @eslint dependencies (#20265) (Francesco Trotta)
• c7d3229 chore: update dependency @eslint/core to ^0.17.0 (#20256) (renovate[bot])
• 27549bc chore: update fuzz testing to not error if code sample minimizer fails (#20252) (Milos Djermanovic)
• a1370ee ci: bump actions/setup-node from 5 to 6 (#20230) (dependabot[bot])
• 9e7fad4 chore: add script to auto-generate eslint:recommended configuration (#20208) (唯然)

Original source Report a problem

Highlights

We just pushed ESLint v9.38.0, which is a minor release upgrade of ESLint. This release adds some new features and fixes several bugs found in the previous release.

This release introduces improvements in determining which configuration to use from plugins that support both old (eslintrc) and new configuration formats. When extending a plugin configuration, for example extends: ["my-plugin/recommended"], the defineConfig() config helper was already looking for configs["flat/recommended"] configuration if configs["recommended"] configuration exists in the plugin but is detected as the eslintrc configuration format.

As of this release:

• The defineConfig() config helper will look for configs["flat/recommended"] configuration even if configs["recommended"] configuration does not exist in the plugin.
• Configurations that have array values as the plugins property will be detected as the eslintrc configuration format.

Other notable changes

• The complexity rule now highlights only the function header instead of the entire function.

Features

• feat: update complexity rule to only highlight function header (#20048) (Atul Nair)
• feat: correct no-loss-of-precision false positives with e notation (#20187) (Francesco Trotta)

Bug Fixes

• fix: improve type support for isolated dependencies in pnpm (#20201) (Francesco Trotta)
• fix: correct SourceCode typings (#20114) (Pixel998)

Documentation

• docs: improve web accessibility by hiding non-semantic character (#20205) (루밀LuMir)
• docs: correct formatting in no-irregular-whitespace rule documentation (#20203) (루밀LuMir)
• docs: Update README (GitHub Actions Bot)
• docs: move custom-formatters type descriptions to nodejs-api (#20190) (Percy Ma)

Chores

• chore: upgrade @eslint/[email protected] (#20221) (Milos Djermanovic)
• chore: package.json update for @eslint/js release (Jenkins)
• refactor: Use types from @eslint/core (#20168) (Nicholas C. Zakas)
• ci: add Node.js 25 to ci.yml (#20220) (루밀LuMir)
• ci: bump github/codeql-action from 3 to 4 (#20211) (dependabot[bot])
• test: remove use of nodejsScope option of eslint-scope from tests (#20206) (Milos Djermanovic)
• chore: fix typo in legacy-eslint.js (#20202) (Sweta Tanwar)
• chore: fix typos (#20200) (ntnyq)
• chore: use team member’s username when name is not available in data (#20194) (Milos Djermanovic)
• chore: mark deprecated rules as available until v11.0.0 (#20184) (Pixel998)

Original source Report a problem

Development plan

Similar 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-alpha

The following changes are planned for the alpha release and represent significant breaking changes.

• Dropping support for Node.js < v20.19.0

Following our Node.js version support policy for major releases, ESLint v10.0.0 will require Node.js v20.19.0 or later. The new supported versions will be:

• Node.js v20.19.0 and above
• Node.js v22.13.0 and above
• Node.js v24 and above

This change aligns with Node.js’s release schedule as of 2025, where:

• Node.js v18 reached end-of-life in April 2025
• Node.js v20 is in Maintenance LTS until April 2026
• Node.js v22 became Active LTS in October 2024

The updated Node.js requirements will enable ESLint to leverage newer JavaScript features, including native support for require(esm) (enabled by default since Node.js v20.19.0), and improved performance characteristics of modern Node.js versions.

• Removal of eslintrc functionality

In ESLint v9.0.0, we deprecated the old eslintrc config system while leaving the functionality available for backwards compatibility. In v10.0.0, we are removing the eslintrc config system completely. Specifically, this means:

• The ESLINT_USE_FLAT_CONFIG environment variable is no longer honored.
• The CLI no longer supports eslintrc-specific arguments (--no-eslintrc, --env, --resolve-plugins-relative-to, --rulesdir, --ignore-path).
• .eslintrc.* and .eslintignore files will no longer be honored.
• The loadESLint() function now always returns the ESLint class.
• The Linter constructor configType argument can only be "flat" and will throw an error if "eslintrc" is passed.
• The following Linter eslintrc-specific methods are removed:
  • defineParser()
  • defineRule()
  • defineRules()
  • getRules()
• The following changes to the /use-at-your-own-risk entrypoint:
  • LegacyESLint is removed
  • FileEnumerator is removed
  • shouldUseFlatConfig() function will always return true

Updating eslint:recommended configuration

The eslint:recommended configuration will be updated for v10.0.0 to include new rules that help catch common programming errors and improve code quality.

Removing support for jiti < 2.2.0

ESLint v10.0.0 will drop support for jiti versions prior to 2.2.0 when loading TypeScript configuration files due to known issues that can cause compatibility problems when configurations load certain plugins (as documented in issue #19413).

Updates to Program AST node range coverage

ESLint v10.0.0 will include a significant change to how the Program AST node’s range is calculated, updating it to span the entire source text.

Currently, the Program node’s range excludes leading and trailing comments/whitespace, which creates some unintuitive scenarios:

// Leading comment
const x = 1;
// Trailing comment

Current: Program range covers only const x = 1; (excludes comments)
New: Program range covers the entire file from start to finish

Removing deprecated rule context members

ESLint v10.0.0 will remove several deprecated members from the rule context object that have been deprecated since ESLint v9.0.0.

The following deprecated context members will no longer be available:

• context.getCwd() - Use context.cwd instead
• context.getFilename() - Use context.filename instead
• context.getPhysicalFilename() - Use context.physicalFilename instead
• context.getSourceCode() - Use context.sourceCode instead
• context.parserOptions - Use context.languageOptions or context.languageOptions.parserOptions instead
• context.parserPath - No replacement

New configuration file lookup algorithm

The v10_config_lookup_from_file flag, which changes configuration lookup to start from the file being linted rather than the current working directory, will become the default in v10.0.0.

This change ensures that ESLint configuration discovery works more intuitively, especially in monorepo setups or when linting files in different directories.

Removal of type property in errors of invalid RuleTester cases

In ESLint v10.0.0, the deprecated type property in errors of invalid test cases for rules will be no longer supported. Using the type property in test cases will throw an error.

Significant changes in v10.0.0-beta

The following changes are planned for the beta release.

Enabling JSX reference tracking

ESLint v10.0.0 will enable JSX reference tracking, allowing ESLint to properly understand JSX element references in scope analysis.

Currently, ESLint doesn’t track JSX references, which creates issues with scope analysis. For example:
import { Card } from "./card.jsx";
export function createCard(name) {
return ;
}

In this code, ESLint doesn’t recognize that is a reference to the imported Card component. This change brings ESLint’s JSX handling in line with developer expectations and improves the overall linting experience for modern JavaScript applications using JSX.

Removal of deprecated SourceCode methods

ESLint v10.0.0 will remove several deprecated SourceCode methods that have been marked for removal since ESLint v5.10.0.

The following deprecated SourceCode methods will be removed:

• getTokenOrCommentBefore() - Replace with getTokenBefore() using the { includeComments: true } option
• getTokenOrCommentAfter() - Replace with getTokenAfter() using the { includeComments: true } option
• isSpaceBetweenTokens() - Replace with isSpaceBetween()
• getJSDocComment() - This functionality will be moved to AST utilities

These methods have been deprecated for multiple major versions and are primarily used by deprecated formatting rules and internal ESLint utilities. Custom rules using these methods will need to be updated to use their modern replacements. The @eslint/compat package will provide compatibility patches to help with the transition.

When to expect ESLint v10.0.0

We expect the first alpha release of ESLint v10.0.0 to be available in November 2025, with the beta following shortly thereafter. The final v10.0.0 release is targeted for January 2026, though the exact timeline will depend on community feedback and testing results.

All releases will be announced on this blog, our X account, our Bluesky account and our Mastodon account. We encourage users to test the alpha and beta releases to help ensure a smooth transition to v10.0.0.

Stay tuned for more detailed information about specific changes as we approach each release milestone.

Update(2025-11-07): We previously planned on removing parserOptions.globalReturn but decided to hold off based on feedback from the community.

Original source Report a problem