Last month, the Technical Steering Committee (TSC) met to finalize the features for ESLint v9.0.0. This post outlines our plans for v9.0.0. You can keep up to date everything that is planned for v9.0.0 on our project board.
Due to the large number of breaking changes planned for v9.0.0, we have decided to develop this release in two phases:
- Alpha. The alpha release will be comprised primarily of the changes we believe will cause the most disruption for existing users. Getting these changes into a release early will allow us to gather feedback to ensure things are going as planned.
- Beta. The beta release will be comprised of the remaining tasks and smaller breaking changes that will have fewer impacted users.
The specific details about each phase are listed below in this post. Note that if tasks scheduled for the beta are completed in the alpha timeframe, then they will be published in the alpha release.
After the beta has been validated, we will publish one or more release candidates as we continue to fix bugs and deal with compatibility issues.
Significant changes in v9.0.0-alpha
The following changes are planned for the alpha release and represent significant breaking changes.
Flat config now the default and has some changes
Flat config will be the default configuration format for ESLint beginning in v9.0.0 and eslintrc will be deprecated but will still work. To continue using a eslintrc configuration file, you’ll need to set the
ESLINT_USE_FLAT_CONFIG environment variable to
false. We announced the details in my previous blog post.
We will also remove the
"eslint:all" configuration strings from flat config. In the initial version of flat config, we let you put these directly into the config array, but in v9.0.0, you’ll need to use the corresponding configs from the
Dropping support for Node.js < v18.18.0, v19
As of this post, Node.js v20.x is the LTS release, and as such we are dropping support for all versions of Node.js prior to v18.18.0 as well as v19.x.
Removing all formatters except
In an ongoing effort to reduce the install size of ESLint, we have decided to remove most of the formatters from the core of ESLint. The formatters being removed are:
If you are using these formatters currently, you’ll need to install the standalone packages for use with ESLint v9.0.0.
Continuing with our theme of reducing ESLint’s install size, we have decided to remove the
require-jsdoc rules. These rules have been deprecated since ESLint v5.10.0 and removing them allows us to remove another dependency (
doctrine). We recommend using the
eslint-plugin-jsdoc plugin instead.
Removing deprecated methods on
As we announced in September, we will be removing a lot of deprecated methods from
context and replacing them with methods on
SourceCode. Please read the above mentioned post for more details on these changes.
Additionally, we will be removing the deprecated
eslint:recommended configuration will be updated to include new rules that we feel are important, and to remove deprecated rules.
Changes to how you write rules
To clean up and make rules easier to work with, we’re making two changes:
- Function-style rules will stop working in v9.0.0. Function-style rules are rules created by exporting a function from a file rather than exporting an object with a
- When a rule doesn’t have
meta.schemaspecified, a default schema of
will be applied. This means that rules without a schema will be assumed to have no options, which in turn means that validation will fail if options are provided.
You can read more about this change in the RFC.
--quiet option is more performant
--quiet option hides all warnings in the ESLint console. In v9.0.0, we are making a performance improvement by also not executing any rules set to
"warn". You can read more about this change in the RFC.
eslint with no file arguments
Starting in v9.0.0, if you are using flat config and you don’t pass any file arguments to the CLI, the CLI will default to linting the current directory, which means you can type
npx eslint and it will just work.
For eslintrc, missing file arguments will result in an error.
Significant changes in v9.0.0-beta
The following changes are planned for the beta release and represent significant breaking changes.
In order to move forward with the language plugins work, we’ll be removing
CodePath#currentSegments. This only affects rules that are using code path analysis. You can read more in the previous blog post.
Configuration comments with just severity now only override severity
Due to a bug in the way inline configuration comments were handled, comments such as
/*eslint no-undef: warn */ would automatically remove any options set for the corresponding rule in a configuration file. In v9.0.0, these types of comments will only change the severity of the rule and will not affect any other options.
no-new-native-nonconstructor rule replaces
no-new-symbol rule was designed to prevent
new Symbol() in your code, which is an error because
Symbol isn’t a constructor. There are other global functions that also don’t have constructors, so we decided to create a new rule,
no-new-native-nonconstructor, to cover all of those cases. This new rule will be added to
no-new-symbol will be deprecated.
RuleTester class will be updated to catch more problems with rules:
- There will be a failure if multiple suggestion fixers have the same message.
- There will be a failure if a suggestion contains a parsing error.
- Several additional assertions will be added to catch invalid or buggy test cases.
When to expect ESLint v9.0.0
We expect the first alpha release of ESLint v9.0.0 to be released in December or January, depending on the progress we make on our tasks. At that point, we will gather feedback from the community and fix any outstanding issues that make it difficult for people to upgrade. We hope to the beta release a couple of months after the alpha, and the final release a couple of months after that. Availability of all releases will be announced on this blog, on our X account, and on our Mastodon account, so please stay tuned!