ESLint v10.0.0-beta.0 released

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
  }
});
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

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} />;
}
1
2
3
4
5

Prior to v10.0.0:

• False positives: <Card> 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, <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
1

You can also specify the version directly:

npm i eslint@10.0.0-beta.0 --save-dev
1

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])