ESLint v2.0.0-beta.1 released

We just pushed ESLint v2.0.0-beta.1, which is a major release upgrade of ESLint. This release adds some new features, including some breaking changes, and fixes several bugs found in the previous release.

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-beta.1 --save-dev

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.

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.

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.

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.

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 Visual Studio Formatter

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.

.eslintignore Changes

The .eslintignore file now works the same .gitignore. This was a long-standing ask from our users that we’ve finally been able to merge. If you hadn’t noticed any difference between the syntax of .eslintignore and .gitignore, then you likely won’t notice any difference with this change. The end result is that you can use .gitignore syntax in .eslintignore (which also means you can use your .gitignore directly as an ignore file for ESLint).