Glob based configuration

[lo1tuma]

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

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[ilyavolodin]

I agree with not allowing this in shareable configs, but I think we should support extends in each pattern. This way you can extend one config for your code, and another for tests.
I would imagine that has to work for CLIEngine, since CLIEngine now can accept a directory.

[lxanders]

As we discussed I really like this @lo1tuma!

If I got you right @ilyavolodin you suggested that this should work:

{
  "files": [
    {
      "patterns": "**/*Spec.js",
      "extends": "someBodysShareableConfig/test-rules"
    }
  ] 
} 

This is exactly what I was already discussing with @lo1tuma. So 2/2 people who commented on this proposal thought this is an important point. Maybe you should add some information in your proposal about this extends part. I think its important.

Ah and one very small idea (just to think about it): Maybe it would be better if the configuration enforced an array for patterns. This way at least the name would match and it would be clear that you can use multiple or one.

Apart from that I will just repeat what I said to you in personal: The files and patterns reads not that bad if you think of it as this configuration should be in place for all files that match specific patterns. Only allowing one pattern would make it better but would mean code duplication in your configuration which is definitely not what one would want.

Maybe someone else has a great idea on it :).

[lo1tuma]

I’ve updated the description to clarify that a glob specific configuration works the same as the regular configuration in an .eslintrc file:

A glob specific configuration works exactly the same as the regular configuration in your .eslintrc. That means you can configure globals, env, ecmaFeatures, rules, plugins, extends and parser.

[nzakas]

I'm uncomfortable with having a difference between shareable and non-shareable configs, as the whole point is to be able to share all your settings. I think configs must all be the same regardless of being shareable or not.

[ilyavolodin]

@nzakas I don't think I agree. Or rather, I understand exactly where you coming from in terms of keeping shareable and non-shareable configs the same, but in my mind, there is a philosophical difference between them. Shareable configs are generic, they are there to setup a skeleton. Personal configs are specific to a project. And file name patterns/folder layout are very specific to projects.

[Nate-Wilkins]

I agree with @nzakas. Can't it just be bad practice or an issue that developers who write shareable configs be aware of?

[ilyavolodin]

As in - convention over configuration? Honestly I was always against that in OSS. People don't read docs:-)

[Nate-Wilkins]

Yeah, I mean it seems pretty reasonable to assume that most developers distributing shareable configs will see those potential issues. And honestly they might want that to force directory structure - not saying it's a good idea but it's a potential option that would be taken away otherwise

[Nate-Wilkins]

I like configuration over convention for some things 👍

@lo1tuma potential name include(s)?

[ilyavolodin]

Ok, I guess I can buy "taken away" argument. In that case @lo1tuma I would imagine root would be the point extends is called from (as in directory of .eslintrc file that has extends in it).

[nzakas]

My point is that you should be able to take a personal config, wrap it in an npm package, and make it a shareable config. That's always been the vision for shareable configs, so anything that gets in the way of that vision is 👎.

Also, let's keep the scope of this fairly small for now. Let's just start with specifying rules, globals, and environments for glob patterns. We can always add more capabilities later, but I think this scope provides most of what people are looking for.

[IanVS]

@lo1tuma, I suddenly have a pressing need for this kind of functionality. Is it something you're still planning to work on?

[lo1tuma]

@IanVS yes, I’ve already started working on this. The hard thing about this is that I don’t want to break the current in-memory caching during resolving the config for a file. Currently the config for multiple files in the same directory is always the same, that’s why it is cached per directory, but this isn’t true anymore if start merging the glob-pattern based configuration during the resolving phase.

[nzakas]

Can we simplify this to apply to extensions only, rather than full glob patterns? Would that make it simpler?

[lo1tuma]

@nzakas I can’t really see how that would make it simpler. The configurations for different files in the same directory would still differ.

[IanVS]

Only applying to extensions would not help me. My use case is I have __spec directories spread throughout the code base, and files in those directories need to have a different environment set from the rest of the code. Currently, each __spec directory needs to contain an eslint config file.

[mgrandrath]

Same for me. I have my tests alongside the production code with the pattern _*_spec.js. And it would be really helpful to apply the mocha env only to files that match this pattern. Just the other day I had the situation that a fellow developer used an undefined context variable in the production code that ESLint was unable to pick up because the mocha env (which defines context as a global) is applied to every file.

[clairebw]

Hi there, any idea if the feature is still being worked on and if there is a rough estimate about the timeframe?

[smably]

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

[marcuswestin]

@not-an-aardvark 👍
Massive patch! Nice work man

[w0rp]

This will be especially useful for configuring .spec.js files for Jasmine tests separately from other code. Thank you for your work on this. 👍

[jquense]

WOOHOO! one of the longest watched issues I had :) great work everyone !

[not-an-aardvark]

@marcuswestin Thanks, but all the credit goes to @smably and @CrabDude for working on this. 😃

[marcuswestin]

@smably & @CrabDude thank you! Impressive patch :+1

[CrabDude]

🎉