Override files globbing logic breaks with --config

Tell us about your environment

• ESLint Version: 5.15.3
• Node Version: 10.15.0
• npm Version: 6.9.0

What parser (default, Babel-ESLint, etc.) are you using?

Please show your full configuration:

Configuration

{
    "overrides": [{
        "files": ["**/blah.js"],
        "rules": {
            "prefer-const": 0
        }
    }],
    "parserOptions": {
        "ecmaVersion": 2018
    },
    "rules": {
        "prefer-const": 2
    }
}

What did you do? Please include the actual source code causing the issue, as well as the command that you used to run ESLint.

In this case, I have a configuration that is inside of my node_modules, or another subdirectory. Using the --config flag, I use that file directly rather than having a config in the root of my project. In the file, as above, I’ve got a glob that should match some files. However, that glob is not matched correctly. In particular, in getConfigVector in config, we use config.baseDirectory to compute a relative path. In this case, because the config is in a sibling directory, that relative path starts with something like ../, which makes the glob always fail.

N/A

eslint --config ./configs/.eslintrc.json .

What did you expect to happen? It seems likely that if someone is using --config, they probably want the globs to be computed relative to cwd rather than wherever that config happens to be on disk.

What actually happened? Please include the actual, raw output from ESLint. Globs are computed relative to the config’s location on disk, which makes them not work super well.

Are you willing to submit a pull request to fix this bug?

[mysticatea]

I have posted an RFC https://github.com/eslint/rfcs/pull/37.

[epmatsw]

6.0.0 has been feature-frozen (breaking change frozen) in April.

Ah, bummer.

I think the current behavior is intentional.

It might be, but I think it’s not optimal. It makes it really difficult to use overrides and the --config option together, especially when the overrides can be in files in mostly-unpredictable locations in node_modules.

(Note: this is in the 5.x series, it’s possible that the overrides changes in 6.x will fix this in some other way or make people write configs that are less likely to trigger this issue)