Support Configuration Cascading and Hierarchy

[slindberg]

This is behavior is described in the eslint documentation.

My particular use case is a rails app that has a large amount of vanilla/jQuery JavaScript, that is being migrated to es6/JSX. The two different code styles/syntaxes are isolated from each other in sub directories, and for various reasons we cannot make them separate repos (yet). Configuration cascading works perfectly to define a separate set of rules for each type.

A more common use case however, is altering a small set of rules from the base config for a test suite. For example, eslint config for es6/JSX app test suite is basically the same as for the app, but globals for mocha must be whitelisted (describe, it, etc.), no-unused-expressions turned off for chai assertions, laxer quotes to avoid mixed single and double quotes in test descriptions, etc. Configuration cascading is the answer to this problem, and is truly essential to using eslint effectively IMHO.

[wfleming]

Hi @slindberg,

We should support this functionality already: we use cascading, directory-specific ESLint configuration in some of our own internal repositories (for similar reasons to what you mentioned), and it's been working.

If you're finding your configurations are not being respected, can you please provide the full content of your .codeclimate.yml, and the contents of your ESLint configuration files and the directory structure they're in? Also, are you running analysis on codeclimate.com or using our CLI? When you're not seeing your configuration respected, can you provide examples of what you expected and what happened (e.g. was a rule triggered that should have been ignored, or vice versa)? Thanks in advance for the details.

[slindberg]

I'm running the analysis on codeclimate.com. I'm attempting to use eslint@2 via the channel: "eslint-2" config option. Prior to opening this issue, I had created a support ticket with CC which I ended up asking about configuration cascading, and the response was:

Unfortunately, we don't support configuration cascading quite yet. As you know, our ESLint engine supports custom config paths -- but we're not able to point it to directory-specific config files. That said, our engine requires rules to be configured in the .eslintrc file -- if it doesn't pick up any rules then it will continue to error builds.

I'm sorry for the limitation with this in the meantime, and for not having a better workaround for you. We've brought this up with my dev team in the past, and it seems like something we'd like to be able to support in the future, but I don't have an ETA on when that would happen just yet.

(The "directory-specific config files" part was in response to another question about specifying multiple different .eslintrc files for subdirectories, to work around cascading not working.)

I've tried a lot of different permutations of .codeclimate.yml and .eslintrc.js, so it will take a while to put them into a comment; before I do that I just want to make sure that the response above was not accurate and you are the source of truth 😉

[wfleming]

Thanks for the response. Sorry for any confusion between my response and your support conversation. We do not support any kind of cascading configuration with .codeclimate.yml: that much is entirely accurate. We do support cascading .eslintrc* files in effectively the same way that vanilla ESLint supports them. Does that clear it up a bit?

[slindberg]

Ah, got it, that does clear it up. After your initial response, I tried a couple more things, and I think what was going on is that the eslint parser settings that allow for es6 module syntax were only in the eslintrc override, not in the base eslintrc in the root directory, and those settings weren't being cascaded, but rules were (although this seems to work fine locally). That was a confusing sentence, but hopefully it made sense. Thanks again!

[wfleming]

Glad you got it working! Sorry for any confusion we caused along the way.