ESLint v7.0.0 is a major release of ESLint. We have made a few breaking changes in this release. This guide is intended to walk you through the breaking changes.
The lists below are ordered roughly by the number of users each change is expected to affect, where the first items are expected to affect the most users.
- Node.js 8 is no longer supported
- Lint the files that match to
overrides[].filesby default - The base path of
overridesandignorePatternsis changed if the config file is given by the--config/--ignore-pathoptions - The place where ESLint loads plugins from is changed
- Runtime deprecation warnings on
~/.eslintrc.*config files - Default ignore patterns are changed
- Description in directive comments
- Node.js/CommonJS rules are deprecated
- Several rules get strict
eslint:recommendedis updated
- Node.js 8 is no longer supported
- Lint the files that match to
overrides[].filesby default - The place where ESLint loads plugins from is changed
RuleTesterclass get strict
- Node.js 8 is no longer supported
- The place where ESLint loads plugins from is changed
CLIEngineclass has been deprecated
Node.js 8 has been at EOL since December 2019. Therefore, we have decided to drop support for it in ESLint 7. We now support the following versions of Node.js:
- Node.js 10 (
10.12.0and above) - Anything above Node.js 12
To address: Make sure you upgrade to at least Node.js 10.12.0 when using ESLint 7. Mind the Node.js version of your editor when you use ESLint 7 via editor integrations. If you are unable to upgrade, we recommend continuing to use ESLint 6 until you are able to upgrade Node.js.
Related issue(s): RFC44, #12700
Previously, ESLint lints only *.js files by default if directories are present such as below.
$ eslint src
In the situation, ESLint 7 lints the files that match to overrides[].files along with *.js files. (But it excepts patterns that end with * in order to avoid linting unlimitedly.) For example, if the following config file is present,
# .eslintrc.yml
extends: my-config-js
overrides:
- files: "*.ts"
extends: my-config-tsthen the eslint src command checks both *.js and *.ts files in the src directory.
To address: Add --ext js option if you are using overrides but don't want to lint other files than *.js. The --ext CLI option overrides this new behavior completely.
If you maintain plugins which check other kinds of files than .js, it may be convenient if the recommended preset of your plugin has the overrides setting in order to check the files by default.
Related issue(s): RFC20, #12677
The base path of overrides and ignorePatterns is changed if the config file is given by the --config/--ignore-path options
ESLint resolves the following paths as relative to the directory path of having the entry config file. (the entry means that the settings of shareable configs are resolved as relative to the directory of having the first extender.)
- Configuration files (
.eslintrc.*)- relative paths in the
overrides[].filessetting - relative paths in the
overrides[].excludedFilessetting - paths which start with
/in theignorePatternssetting
- relative paths in the
- Ignore files (
.eslintignore)- paths which start with
/
- paths which start with
ESLint 7 keeps this behavior in most cases, but only if the config file is given via either --config path/to/a-config or --ignore-path path/to/a-ignore options then ESLint resolves those paths as relative to the current working directory rather than the file location.
To address: Update those paths if you are using the config file via --config or --ignore-path CLI options.
Related issue(s): RFC37, #12887
Previously, ESLint resolves all plugins from the current working directory by default.
Since ESLint 7, it resolves the plugins setting as relative to the directory of having the entry config file. (the entry means that the plugins setting of shareable configs is resolved as relative to the directory of having the first extender.)
This will not change anything in most cases. If a config file in a subdirectory has plugins setting, the plugins will be loaded from the subdirectory (or ancestor directories that include the current working directory if not found).
If you are using a config file of a shared location via --config option, the plugins the config file declare will be loaded from the shared location.
To address: Install plugins to the proper place or add --resolve-plugins-relative-to . option to override this change.
Related issue(s): RFC47, #12922
Personal config files have been deprecated since v6.7.0. As planned, v7.0.0 has started to print runtime deprecation warnings. It prints the warnings when the following situations:
- When ESLint loaded
~/.eslintrc.*config files because project's config was not present. - When ESLint ignored
~/.eslintrc.*config files because project's config was present. (in other words, the HOME directory is an ancestor directory of the project and the project config didn't haveroot:truesetting.)
To address: Remove ~/.eslintrc.* config files then add .eslintrc.* config files to your project directory. Or use --config option to use shared config files.
Related issue(s): RFC32, #12678
Previously, ESLint ignores the following files:
- Dotfiles (
.*) node_modulesin the current working directory (/node_modules/*)bower_componentsin the current working directory (/bower_components/*)
ESLint 7 ignores node_modules/* of subdirectories as well, but no longer ignores bower_components/* and .eslintrc.js. Therefore, the new default ignore patterns are:
- Dotfiles except
.eslintrc.*(.*but not.eslintrc.*) node_modules(/**/node_modules/*)
To address: Modify your .eslintignore or the ignorePatterns property of your config file if you don't want to lint bower_components/* and .eslintrc.js.
Related issue(s): RFC51, #12888
Previously, ESLint doesn't have the official way to write the reason for directive comments like /*eslint-disable*/, but it's better if directive comments have the reason description.
ESLint 7 ignores the part preceded by -- in directive comments. For example:
// eslint-disable-next-line a-rule, another-rule -- those are buggy!!To address: If you have -- surrounded by whitespaces in the configuration in directive comments, consider to move it to your config file.
Related issue(s): RFC33, #12699
Ten rules about Node.js/CommonJS are deprecated and moved to the eslint-plugin-node plugin.
To address: As our deprecation policy, you can continue to use the deprecated rules. But the source code of the deprecated rules has been frozen, so we don't fix any bugs of those rules anymore. Therefore, we recommend using the corresponded plugin rules instead.
Related issue(s): #12898
Several rules now report more errors as enhancement:
- accessor-pairs rule now recognizes class members by default.
- array-callback-return rule now recognizes
flatMapmethod. - computed-property-spacing rule now recognizes class members by default.
- func-names rule now recognizes function declarations in default exports.
- no-extra-parens rule now recognizes parentheses in assignment targets.
- no-dupe-class-members rule now recognizes computed keys if it's static.
- no-magic-number rule now recognizes bigint literals.
- radix rule now recognizes invalid numbers at the second parameter of
parseInt(). - use-isnan rule now recognizes class members by default.
- yoda rule now recognizes bigint literals.
To address: Modify your code if new warnings appeared.
Related issue(s): #12490, #12608, #12670, #12701, #12765, #12837, #12913, #12915, #12919
Three new rules are enabled by the eslint:recommended preset.
To address: Modify your code if new warnings appeared.
Related issue(s): #12920
The RuleTester now recognizes more mistakes:
- It fails test-cases if the rule uses either of non-standard properties
node.startandnode.end. Usenode.rangeinstead. - It fails test-cases if the rule provides autofix but the test-case doesn't have the
outputproperty. Add theoutputproperty to test autofix. - It fails test-cases if any unknown properties are found in the objects in the
errorsproperty.
To address: Modify your rule or test-case if existing test-cases failed.
Related issue(s): RFC25, #12096, #12955
CLIEngine class has been deprecated and replaced by new ESLint class.
Because CLIEngine class provides synchronous API but we have a bundle of features that we cannot implement on the synchronous API such as parallel linting, ES modules, and printing progress. Therefore, the new ESLint class provides only asynchronous API and we deprecate CLIEngine class.
To address: Use ESLint class if you are using CLIEngine class. The ESLint class has similar methods:
CLIEngine |
ESLint |
|---|---|
executeOnFiles(patterns) |
lintFiles(patterns) |
executeOnText(text, filePath, warnIgnored) |
lintText(text, options) |
getFormatter(name) |
loadFormatter(name) |
getConfigForFile(filePath) |
calculateConfigForFile(filePath) |
isPathIgnored(filePath) |
isPathIgnored(filePath) |
static outputFixes(results) |
static outputFixes(results) |
static getErrorResults(results) |
static getErrorResults(results) |
static getFormatter(name) |
(removed ※1) |
addPlugin(pluginId, definition) |
the plugins constructor option |
getRules() |
(not implemented yet) |
resolveFileGlobPatterns() |
(removed ※2) |
- ※1 The
engine.getFormatter()method had returned the object of loaded packages as-is. It had made hard to add new features to formatters for backward compatibility of third-party formatters. So the neweslint.loadFormatter()method returns the adapter object that wraps the object of loaded packages. It will ease adding new features as being able to provide default stuff. The adapter object may access toESLintinstance to make default stuff (for example, it uses loaded plugin rules to makerulesMeta). Therefore,ESLintclass doesn't have the static version ofloadFormatter()method. - ※2 Since ESLint 6, ESLint uses a different logic from the
resolveFileGlobPatterns()method to iterate files. Therefore, we obsolate it.