Glob based configuration

Glob based configuration

Goal

Currently ESLint allows you to cascade the configurations based on the directory structure of your project. This approach is not flexible enough if you have files that don’t share the same parent directory but you still want to have a specific ESLint configuration just for those files. This could be solved by specifying a configuration that applies to all files which match a given glob pattern.

How it works

• The glob patterns can be configured within .eslintrc files
• glob patterns are relative to the location of the .eslintrc in which they are defined
• if an already resolved file matches a glob pattern in one of its corresponding .eslintrc files, the glob pattern specific configuration will be applied
• a glob pattern based configuration has a higher precedence than the regular configuration in the same .eslintrc file
• A glob specific configuration works exactly the same as the regular configuration in your .eslintrc, except that you can’t define nested glob based configurations. That means you can configure globals, env, ecmaFeatures, rules, plugins, extends and parser.

Note: The glob patterns are NOT used for file resolving / directory traversal.

Example for relative glob patterns

Given the following directory tree:

project-root
├── app
│   ├── lib
│   │   ├── foo.js
│   │   ├── fooSpec.js
│   ├── components
│   │   ├── bar.js
│   │   ├── barSpec.js
│   ├── .eslintrc
├── server
│   ├── server.js
│   ├── serverSpec.js
├── .eslintrc

The config in app/.eslintrc defines the glob pattern **/*Spec.js. This pattern is relative to the base directory of app/.eslintrc. So, this pattern would match app/lib/fooSpec.js and app/components/barSpec.js but NOT server/serverSpec.js. If you would define the same pattern in the .eslintrc file within in the project-root folder, it would match all three of the *Spec files.

Configuration Examples

Single pattern

{
  "files": [
    {
      "patterns": "**/*Spec.js",
      "rules": { "no-unused-expression": 0 },
      "env": { "mocha": true } 
    }
  ] 
} 

Multiple patterns

{
  "files": [
    {
      "patterns": [ "app/components/**/*.js", "test/unit/app/components/**/*.js" ],
      "rules": { "react/display-name": 2 },
      "ecmaFeatures": { "jsx": true },
      "plugins": [ "react" ] 
    }
  ] 
} 

As you can see patterns could be a string for a single glob pattern or an array if you like to define multiple patterns.

Open Questions / Possible Problems

• Should we allow patterns in shareable configs? To which base path should the relative glob pattern be resolved? I think we should not allow this. Extending from a shareable config should mean that you unconditionally get the rules from this shareable configuration for all the files that you configure it in your project
• Should this feature also work somehow for the CLIEngine?

---

PS: I’m not happy with the current naming of "files" and "patterns". Suggestions welcome

<bountysource-plugin>

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource. </bountysource-plugin>

[smably]

Can’t speak to timeframe, but work is progressing in #8081.

[w0rp]

I’m looking forward to this feature, as it will allow me to specify that every file ending in .spec.js, containing tests, should permit a different set of globals for writing Jasmine tests. This is a pretty common pattern for AngularJS code.