ESLint v2.12.0 released

We just pushed ESLint v2.12.0, which is a minor release upgrade of ESLint. This release adds some new features and fixes several bugs found in the previous release.


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

JSCS Compatibility

We are continuing to work on compatibility with JSCS, and in this release we added two new rules that correspond to JSCS rules:

Introducing eslint:all

We’ve had numerous requests to provide a configuration that turns on all rules ESLint provides. You can now set extends in your configuration file equal to "eslint:all" to get every core rule enabled with their default settings.

Important: This configuration is not recommended for production use because it changes with every minor and major version of ESLint. Use at your own risk.

You can read more in the documentation.

Performance Improvement

You might have seen this case study of debugging a performance issue in ESLint at Google I/O. A pull request was filed during the talk that showed some significant performance improvement. There were some details of the pull request that weren’t quite correct and caused some regressions, however, we were able to adopt the basic approach to realize some of the performance improvements.

In #6276, we enabled this improvement for anyone who is either not using .eslintignore or is using .eslintignore without specifying a re-inclusion pattern (beginning with !). This showed a significant performance improvement when run on the ESLint repo itself and we expect developers with large projects (especially those with a node_modules directory) to see savings of whole seconds when linting everything (such as using eslint .). If you already manually pass in filenames on the command line, you won’t see any improvement because the gains are on directory traversal.

Formalized Semantic Versioning Policy

One of the things that JSCS did well was formally defining their semantic versioning policy. In the world of linters, it’s not always clear whether something should be a patch or a minor version bump. For instance, what if a rule has a bug where it’s not finding problems that it should? While we could classify that as a bug, fixing the bug could cause ESLint users’ lint builds to break, which is unexpected in a patch version.

The JSCS team had a really well-reasoned semantic versioning policy to give their users a clear picture of when to expect lint build breakage. We decided to adopt a policy based on the JSCS one and have posted it on our README. The end result is that we are taking breaking your lint builds very seriously and want to be clear when such breakages can occur and why.

All New Rules

The complete list of new rules in this release:



Bug Fixes