Support specifying extensions in the config
sindresorhus opened this issue · comments
The version of ESLint you are using.
v5.5.0
The problem you want to solve.
It's currently only possible to specify the extensions of the files to lint with the --ext CLI flag. This creates an annoying user-experience for sharable configs that adds support for non-JS environments. For example, if someone wants to use my eslint-config-xo-typescript shareable config, they need to run ESLint with eslint . --ext=ts.
Your take on the correct solution to problem.
It should be possible to specify an extension in the ESLint config. This makes it possible to create a shareable config that can be used directly without having to use any CLI flags.
For example:
module.exports = {
extensions: [
'md'
]
rules: {
// …
}
};I don't see any downside with supporting this. And it would also make it easier to use ESLint with non-JS files in non-CLI situations like editors and with wrappers like XO and Standard.
@ilyavolodin Do you have any background on why --ext is currently a command-line flag rather than a config option?
I think it was done for historical reasons. ESLint originally only supported js files. Once we added support for jsx we had the need to also lint jsx files, but at that point, all the rules that would apply to js files would also apply to jsx files, so there was no reason to create separate configurations for extensions. As such it was added as a command line flag. @nzakas wanted to change the functionality of how extensions are specified and also modify the way preprocessors are configured, but we never got around to doing that.
That being said, the way ESLint works is that config files are constructed after the files that are supposed to be linted are found. So if you specify extensions in the config, it's going to be too late at that point to find appropriate files.
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.
@not-an-aardvark @ilyavolodin Can this be reopened please? It's a sorely needed feature and the issue has many upvotes.
Also think it should be re-opened. Doesn't feel very intuitive when the end user has to specify CLI flags for certain configs to work. I think that should be specified by the config itself making it "self-contained".
Self-assign to prevent auto closing and for discussion.
Does it make sense to add ts and tsx to the default extensions for the next major? And throw a pretty errors saying the user need the parser from @typescript-eslint if it's missing and a TS(X) file is found? Might be too tight of a coupling, not sure.
Although of course if config could specify it, that would probably solve it as well. I'm not sure how many people extend the eslint plugin's recommended config (it has a bunch of stylistic rules, so it might be that people just add the parser without the plugin?)
For current JavaScript eco-system, not only .ts and .tsx but also .vue is widely used. So, modifying default extensions may not be a good solution, however, allowing to specify extensions in config file would be useful.
I don't see how we can make this happen. As I mentioned, configs are constructed after globs are resolved (that's how we know where to look for configs to begin with). If extensions are going to be in config files, we will not know them soon enough to construct correct globs. For example, if you have a subfolder with only .ts files in it, and config file that specifies how those TypeScript files have to be linted, as well as that they should be included, how do we know that this config needs to be picked up?
We could possibly restructure the whole file traversal to first search for .eslintrc.* files, and then, based on the specified extensions search for files to be linted, but first of all - it would mean two file system traversal instead of one, second - it would significantly complicate file resolutions process, since if a subfolder contains "extensions: '.ts'" (for example), only that subfolder and it's child's folders should be scanned for .ts files.
Babel added what they call "project-wide" configuration (more details there)
They have .babelrc (the name looks a lot like .eslintrc) which is file-relative (also looks similar to .eslintrc), and babel.config.js which is project-wide. A project-wide configuration may be a good place to configure extensions and cache. Also it would introduce similarities for whoever is using both eslint and babel.
I'm not praising babel's solution, I found it weird the first time I read it, but I think it's worth consideration to solve this issue.
The new ESLint config format proposal might resolve this: eslint/rfcs#9
Hi. #11546 changed the processing order to "config-then-files" from "files-then-config". Now ESLint loads config files before globs resolved, so there are no technical barriers to implement this.
There are some related RFCs: eslint/rfcs#20, eslint/rfcs#22
Personally, I hope to go with eslint/rfcs#20, though it's on 7.0.0 line since 6.0.0 has been feature-frozen.
@mysticatea Is there an eta for this (or v7)?
No rush, just wondering because I'm making a custom wrapper for ESLint (as well as other dev tools) to solve some repetitive issues I have across my projects, I was going to bake the extension handling into it, but if v7 comes out soon(ish), I was thinking I might as well leave it out
I think, we will start to publish v7 alpha releases December 2019 or January 2020.