ESLint v4.1.0 released

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

Highlights

Glob-based configuration

Previously, it was not possible to use different ESLint configurations for two different files in the same directory. For example, projects that place test files in the same directory as the corresponding source files were unable to use different ESLint configurations for the test files. Adding support for this has been one of our most requested features.

This release adds support for glob-based configuration via an overrides key in a config file, which can be used to apply a configuration to specific globs. For example, you can now enable the mocha environment on only test files, with the following config:

module.exports = {
  rules: {
    // ... the rest of your config (applied to all files)
  },
  overrides: [
    {
      files: ["foo/**/*.spec.js", "bar/**/*.spec.js"],

      // Override config (only applied to files that match the given globs)
      env: { mocha: true }
    }
  ]
};

For full details, see the documentation.

Ignoring files from package.json

It’s common for users to use an .eslintignore file to indicate the files that they would like ESLint to ignore. However, if you don’t want to add additional files to your project root, you can now ignore files by setting the eslintIgnore property in a package.json file to a list of globs:

{
  "eslintIgnore": [
    "build/**/*.js",
    "dist/**/*.js"
  ]
}

Also see: documentation

Applying multiple autofixes simultaneously

When writing a custom rule that can automatically fix problems, one sometimes needs to apply multiple fixes atomically. For example, if an autofix adds parentheses around a piece of source code, adding only one parenthesis will result in a syntax error. Since ESLint does not guarantee that it will be able to apply every fix without conflicts, it was previously not possible to atomically apply multiple fixes (without using confusing workarounds).

Starting in 4.1.0, if you return an array of fixes from a fix function rather than a single fix, all the fixes in the array will be applied atomically.

context.report({
  node,
  message,
  fix(fixer) {
    return [
      fixer.insertTextBefore(node, "("),
      fixer.insertTextAfter(node, ")")
    ]
  }
})

Also see: Autofixing docs

Applying autofixes from Linter

When using ESLint’s Node.js API, it was previously not possible to get automatic fix information for a given source code and configuration when using eslint.Linter. Instead, one had to use eslint.CLIEngine, which is more general and less easy to use.

Starting in 4.1.0, you can now use Linter#verifyAndFix to get autofixing information when using Linter. (You should still use CLIEngine if you need to do more general operations, such as reading config files from the filesystem.)

For more details, see the documentation.

Other highlights

Full Changelog

Features

Enhancements

Bug Fixes

Documentation

Chores