Override files globbing logic breaks with --config

[epmatsw]

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?

[eslint-deprecated]

Unfortunately, it looks like there wasn't enough interest from the team
or community to implement this change. While we wish we'd be able to
accommodate everyone's requests, we do need to prioritize. We've found
that issues failing to reach accepted status after 21 days tend to
never be accepted, and as such, we close those issues.
This doesn't mean the idea isn't interesting or useful, just that it's
not something the team can commit to.

Thanks for contributing to ESLint and we appreciate your understanding.

[epmatsw]

Never even triaged :(

[platinumazure]

Apologies @epmatsw, the ESLint team has been very busy lately and things have slipped through the cracks. I'll reopen this.

[platinumazure]

@eslint/eslint-team Thoughts? This seems like undesirable behavior to me.

[aladdin-add]

what if creating an eslint config in cwd?
maybe it's related to the glob matching, I've encountered a similar issue a while ago.

[mysticatea]

ESLint makes the paths to source codes to the relative paths from the config file then compares with glob patterns.

By the way, how does --ignore-path option handle paths? I think that we should do a same.

[epmatsw]

Wrote up a quick demo in https://github.com/epmatsw/eslintglobs.

npm test demonstrates this bug. I think src/a.js should not have no-var applied because the override should disable it, but it is flagged. src/b.js should be ignored, and it is.

npm run control runs a control test where it uses the same configuration but in a different location. I would expect the behavior to be the same, but in this case we get the expected behavior where src/a.js is correctly not flagged.

Basically, to answer @mysticatea's question, it looks like --ignore-path is computed relative to the cwd, while override globs are computed relative to the config file's location.

[mysticatea]

Hmm.

• .eslintignore patterns are now resolved from the location of the file, since ESLint 4.0.0.
• Default ignore patterns are handled as relative to CWD (Fix: always resolve default ignore patterns from CWD (fixes #9227) #10638).

The two indicate the paths are relative to the .eslintignore file.
I think our intention is that all paths are relative to the file which the path is written. But if a path is not written in any file, the path is relative to CWD.

However, .eslintignore may have a bug since #5627 because it adds the content of --ignore-path file into the default ignore data as well. (Honestly, I don't fully understand the IgnoredPaths class...)

On the other hand, "Ignoring Files and Directories" section says "Paths are relative to .eslintignore location or the current working directory." But this description is not changed since ESLint 2.0.0; I think this documentation is outdated.

[epmatsw]

Any more thoughts on this? Seems like it would probably be a breaking change to fix it, and it looks like the window for 6.0 is closing soon...

[mysticatea]

• 6.0.0 has been feature-frozen (breaking change frozen) in April.
• I think the current behavior is intentional.

[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)

[gziolo]

I run into exactly the same issue as I learned after filing #12278 which was closed as a duplicate. You can find more details there. I also think that ESLint should scan from the project’s current directory when executing with —config option.

[mysticatea]

I have posted an RFC eslint/rfcs#37.