Support specifying extensions in the config

[sindresorhus]

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.

[not-an-aardvark]

@ilyavolodin Do you have any background on why --ext is currently a command-line flag rather than a config option?

[ilyavolodin]

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.

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

[sindresorhus]

@not-an-aardvark @ilyavolodin Can this be reopened please? It's a sorely needed feature and the issue has many upvotes.

[kevva]

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".