New Dec 12, 2025

ESLint v10.0.0-beta.0 released

Libraries, Frameworks, etc. All from ESLint Blog View ESLint v10.0.0-beta.0 released on eslint.org

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.

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:

Starting with v10.0.0, <Card> 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 eslint@10.0.0-beta.0 --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

Features

Bug Fixes

Documentation

Chores

Scroll to top