ESLint v2.0.0 released

We just pushed ESLint v2.0.0, which is the second major release of ESLint. When ESLint began in 2013, we had no idea just how big it would grow. This release is the result of years of feedback, development, and planning to get ESLint to be even better for our users.

In this announcement, we are including all changes from each of the release candidates to make it easier to see what changed from the release candidates to now.

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.

Highlights

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

Installing

Since this is a major release version, you will not automatically be upgraded by npm in most cases. You must specify the latest tag when installing:

npm i eslint@latest --save-dev

You can also specify the version directly:

npm i eslint@2.0.0 --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.

Read more @ ESLint