Versions

Feature Flags

ESLint ships experimental and future breaking changes behind feature flags to let users opt-in to behavior they want. Flags are used in these situations:

  1. When a feature is experimental and not ready to be enabled for everyone.
  2. When a feature is a breaking change that will be formally merged in the next major release, but users may opt-in to that behavior prior to the next major release.

Flag Prefixes

The prefix of a flag indicates its status:

  • unstable_ indicates that the feature is experimental and the implementation may change before the feature is stabilized. This is a “use at your own risk” feature.
  • v##_ indicates that the feature is stabilized and will be available in the next major release. For example, v10_some_feature indicates that this is a breaking change that will be formally released in ESLint v10.0.0. These flags are removed each major release, and further use of them throws an error.

A feature may move from unstable to being enabled by default without a major release if it is a non-breaking change.

The following policies apply to unstable_ flags.

  • When the feature is stabilized
    • If enabling the feature by default would be a breaking change, a new v##_ flag is added as active, and the unstable_ flag becomes inactive. Further use of the unstable_ flag automatically enables the v##_ flag but emits a warning.
    • Otherwise, the feature is enabled by default, and the unstable_ flag becomes inactive. Further use of the unstable_ flag emits a warning.
  • If the feature is abandoned, the unstable_ flag becomes inactive. Further use of it throws an error.
  • All inactive unstable_ flags are removed each major release, and further use of them throws an error.

Active Flags

The following flags are currently available for use in ESLint.

Flag Description
unstable_config_lookup_from_fileLook up `eslint.config.js` from the file being linted.

Inactive Flags

The following flags were once used but are no longer active.

Flag Description Inactivity Reason
unstable_ts_configEnable TypeScript configuration files.This feature is now enabled by default.

How to Use Feature Flags

Because feature flags are strictly opt-in, you need to manually enable the flags that you want.

Enable Feature Flags with the CLI

On the command line, you can specify feature flags using the --flag option. You can specify as many flags as you’d like:

npm

npx eslint --flag flag_one --flag flag_two file.js 

yarn

yarn dlx eslint --flag flag_one --flag flag_two file.js 

pnpm

pnpm dlx eslint --flag flag_one --flag flag_two file.js 

bun

bunx eslint --flag flag_one --flag flag_two file.js 

Enable Feature Flags with the API

When using the API, you can pass a flags array to both the ESLint and Linter classes:

const { ESLint, Linter } = require("eslint");

const eslint = new ESLint({
    flags: ["flag_one", "flag_two"]
});

const linter = new Linter({
    flags: ["flag_one", "flag_two"]
});

Enable Feature Flags in VS Code

To enable flags in the VS Code ESLint Extension for the editor, specify the flags you’d like in the eslint.options setting in your settings.json file:

{
  "eslint.options": { "flags": ["flag_one", "flag_two"] }
}

To enable flags in the VS Code ESLint Extension for a lint task, specify the eslint.lintTask.options settings:

{
  "eslint.lintTask.options": "--flag flag_one --flag flag_two ."
}
Change Language