ESLint v2.0.0-rc.1 released

We just pushed ESLint v2.0.0-rc.1, which is a preview release upgrade of ESLint. As such, we have duplicated some of the content from the previous blog posts to make it easier to understand the differences between v1.10.3 and this version.

Note: 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 having any problems or feedback by creating issues.

Highlights

This is a summary of the major changes you need to know about for this version of ESLint.

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@2.0.0-rc.1 --save-dev

Migration Guide

As there are a lot of changes, we’ve created a migration guide describing the changes in great detail along with the steps you should take to address them. Not all ESLint users will be affected by the changes, however, the changes are big enough that we recommend everyone read the migration thoroughly.

Code Path Analysis

ESLint v2.0.0 formally introduces code path analysis. While we’ve tried to make best guesses at how execution flowed through code, there were several instances where we just couldn’t get everything correct. For instance, trying to guarantee that every code path contained a return statement. Fully implementing code path analysis means that we (and you, through custom rules) can now correctly understand how execution is proceeding through code. Several rules have been updated to make use of code path analysis, fixing some longtime bugs in existing rules. As a result, ESLint is even better at picking up certain types of errors.

Configuration Cascading Changes

Prior to 2.0.0, if a directory contained both an .eslintrc file and a package.json file with ESLint configuration information, the settings from the two files would be merged together. In 2.0.0, only the settings from the .eslintrc.* file are used and the ones in package.json are ignored when both are present. Otherwise, package.json can still be used with ESLint configuration, but only if no other .eslintrc.* files are present.

Read more in the migration guide.

Language Options

Prior to 2.0.0, the way to enable language options was by using ecmaFeatures in your configuration. In 2.0.0:

Read more in the migration guide.

Plugin Changes

This version of ESLint introduces several changes to plugins (see documentation for details):

  1. rulesConfig is no longer supported. We had received complaints from users who didn’t know that plugins could automatically turn on certain rules, and that functionality doesn’t make sense because ESLint rules are supposed to be off by default. As such, rulesConfig will no longer set rules to be on or off by default.
  2. Plugins can now export environments. Environments are used to group global variables and parser options together, and now plugins can define custom environments.
  3. Plugins can now export shareable configs. Instead of needing to have a separate package for a shareable config, they can be bundled directly with the plugin.

Autoconfiguration

The --init option has been enhanced with a new ability: autoconfiguration. Now, in addition to answering a questionnaire or using a popular shareable config, you can also specify files to inspect to generate your configuration. This will create a configuration file that is based on the most common patterns found in your code. Read more about this feature in IanVS’s blog post.

Shareable Config Changes

Shareable configs now evaluate both the parser and extends fields as relative to the location of the config file itself. So you can use relative paths in both fields, and references to npm packages first check the node_modules directory in the same directory as the shareable config.

Unicode BOM Support

If your files use a Unicode BOM, ESLint now properly handles parsing and evaluating your code and won’t get confused by its presence.

Built-In Global Variables

Prior to 2.0.0, new global variables that were standardized as part of ES6 such as Promise, Map, Set, and Symbol were included in the built-in global environment. This could lead to potential issues when, for example, no-undef permitted use of the Promise constructor even in ES5 code where promises are unavailable. In 2.0.0, the built-in environment only includes the standard ES5 global variables, and the new ES6 global variables have been moved to the es6 environment.

Read more in the migration guide.

eslint:recommended Updated

We’ve updated the rules we recommend as a starting point. If you’re extending eslint:recommended, then you should double-check your code after upgrading as there are new recommended rules (all of the added rules help identify errors, no stylistic rules were added).

Removing no-arrow-condition, Adding no-confusing-arrow

In looking at our rules, we discovered that no-arrow-condition actually overlapped with no-constant-condition, so we have removed no-arrow-condition as a core rule. The no-constant-condition will pick up the same errors as no-arrow-condition.

There was an additional condition that had been part of no-arrow-condition incorrectly, which checked for the use of arrow functions in conditional expressions. This functionality is now in the no-confusing-arrow rule.

New Formatters

We’ve added a new formatter called visualstudio, which formats the results into a format that Visual Studio understands. If you use Visual Studio with ESLint, this new formatter makes the console output interactive, so you can click on a warning and be taken straight to the location in the file.

There’s also a new table formatter that outputs ESLint results in a table instead of free-form.

Calculate and Print Config for File

You can now calculate and print out the configuration used to lint any file by using the --print-config flag on the command line. This allows you to specify one file and have ESLint output the complete configuration that will be used to lint that file, including all cascading and inheritance. For instance:

$ eslint --print-config myfile.js

This will output, in JSON format, the calculated configuration for myfile.js without actually linting the file. This is most helpful when trying to debug configuration issues.

New Rules

There are several new rules for this release:

Breaking Changes (v2.0.0-rc.0)

Breaking Changes (v2.0.0-beta.3)

Breaking Changes (v2.0.0-beta.2)

Breaking Changes (v2.0.0-beta.1)

Breaking Changes (v2.0.0-alpha-2)

Breaking Changes (v2.0.0-alpha-1)

Features (v2.0.0-rc.1)

Features (v2.0.0-rc.0)

Features (v2.0.0-beta.3)

Features (v2.0.0-beta.2)

Features (v2.0.0-beta.1)

Features (v2.0.0-alpha-2)

Features (v2.0.0-alpha-1)

Enhancements (v2.0.0-rc.1)

Enhancements (v2.0.0-rc.0)

Enhancements (v2.0.0-beta.3)

Enhancements (v2.0.0-beta.2)

Enhancements (v2.0.0-beta.1)

Enhancements (v2.0.0-alpha-2)

Enhancements (v2.0.0-alpha-1)

Bug Fixes (v2.0.0-rc.1)

Bug Fixes (v2.0.0-rc.0)

Bug Fixes (v2.0.0-beta.3)

Bug Fixes (v2.0.0-beta.2)

Bug Fixes (v2.0.0-beta.1)

Bug Fixes (v2.0.0-alpha-2)

Bug Fixes (v2.0.0-alpha-1)

Documentation (v2.0.0-rc.1)

Documentation (v2.0.0-rc.0)

Documentation (v2.0.0-beta.3)

Documentation (v2.0.0-beta.2)

Documentation (v2.0.0-beta.1)

Documentation (v2.0.0-alpha-2)

Documentation (v2.0.0-alpha-1)

Dependency Upgrades (v2.0.0-beta.2)

Dependency Upgrades (v2.0.0-beta.1)

Dependency Upgrades (v2.0.0-alpha-2)

Dependency Upgrades (v2.0.0-alpha-1)