houndci
eslint: config file resolution / multiple config files
Hound currently only supports specifying single ESLint config file to be used for the whole repository. Unfortunately this does not play nicely with monorepos or repositories with different types of JS source files that have different linting requirements.
Quoting from the ESLint docs:
The first way to use configuration files is via .eslintrc.* and package.json files. ESLint will automatically look for them in the directory of the file to be linted, and in successive parent directories all the way up to the root directory of the filesystem (unless
root: trueis specified). This option is useful when you want different configurations for different parts of a project or when you want others to be able to use ESLint directly without needing to remember to pass in the configuration file.
It would be great, if Hound could support / use the same resolution logic for ESLint projects. Instead of specifying the config file explicitly, you would just specify the files / directories to be linted and let ESLint handle the config resolution.
This repo describes why you would want to use different ESLint configs in the same repo: @clark/eslint-config-ember
Thank you for considering!
Is there any possibility of getting this functionality? It is becoming a blocker for our continued usage of Hound which we really like.
@TomasBarry Could you describe how you are using multiple configuration files?
As described in the OP, it's not likely to be supported as "Instead of specifying the config file explicitly, you would just specify the files / directories to be linted" because that's just not how Hound works, and we need to preserve the behavior for all the current users.
One possible solution for multiple configs could be something like:
eslint:
enabled: true
config_files:
- .eslintrc
- .prettierrc
- test/.eslintrc
Where the first two files would be placed at the root, and the last tested in test/ when a file like test/foo/bar.js. Would something like that fit your use case?
@gylaz, an exaggeration of our scenario would be a directory structure such as:
foo/
--bar/
----bar.js
----.eslintrc.json
--baz/
----baz.js
----.eslintrc.json
--foo.js
--.eslintrc.json
Where all 3 eslintrc.json files have conflicting rules (let's say the top-level .eslintrc.json files requires semicolons but the .eslintrc.json files in bar/ and baz/ don't) therefore Hound should use a different .eslintrc.json file depending on what file it is linting.
So if a change is made to foo.js, it should use the top-level .eslintrc.json file (and require semicolons, for example), but a change to bar.js should use the foo/bar/.eslintrc.json configuration (and not allow semicolons, for example.
Does that make sense?
I believe your suggestion would suit our needs - files in a directory are linted under the rules outlined by the .eslintrc.json file for that directory (and if Hound needs to be given the path to each .eslintrc.json file, that is fine too so long as it uses the appropriate .eslintrc.json file when linting).
In the example you provided, foo/.eslintrc.json would by default be applicable to foo/bar/bar.js and foo/baz/baz.js. Only, if foo/bar/.eslintrc.json and foo/baz/ .eslintrc.json specify root: true, foo/.eslintrc.json would not apply to them.
Assuming, foo/bar/.eslintrc.json and foo/baz/.eslintrc.json do specify root: true, would Hound be smart enough to understand that foo/.eslintrc.json should not lint the foo/bar and foo/baz directories?
You are correct, I gave a bad example. Basically, we are following the instructions here to have a root set of rules and then extra rules based on the given directory.
But Hound is only running the code against the root set of rules.
Our specific example is that the root .eslintrc.json file does not require a comma dangle, but one of our subdirectories has a .eslintrc.json file that does ("comma-dangle": ["error", "always-multiline"],).
So we have a file, in the subdirectory that should require a comma dangle in a Pull Request. However, Hound sees the comma dangle as a violation because the root .eslintrc.json file does not require the comma dangle and sees it as a violation but we would like Hound to lint against the .eslintrc.json file in the subdirectory so that the file in our Pull Request would not have a violation.
Assuming, foo/bar/.eslintrc.json and foo/baz/.eslintrc.json do specify root: true, would Hound be smart enough to understand that foo/.eslintrc.json should not lint the foo/bar and foo/baz directories?
Yes, because in the end Hound shells out to ESLint and let's it do its thing. The only difference is we selectively fetch only the necessary files for the lint to happen.
But Hound is only running the code against the root set of rules.
That's because currently Hound only knows about a single configuration file.
@gylaz, so is it be possible to inform Hound of the extra eslintrc.json files?
