ext does not work as expected

[monolithed]

let lint = new CLIEngine({
	ext: '.js'
});

let report = lint.executeOnFiles([
	'package.json'
]);

Actual

  ⚠  http://eslint.org/docs/rules/  File ignored because of a matching ignore pattern. Use "--no-ignore" to override  
  /tests/runner.js:0:0
  

  ✘  http://eslint.org/docs/rules/  Parsing error: Unexpected token :                                                 
  /tests/package.json:2:8
  	"name": "@qa/yoda-e.mail.ru",
  	       ^

Expected

package.json should be ignored

[ilyavolodin]

ext works a bit differently. Instead of enforcing linting only files with provided extensions, what it does is tells eslint that when we do glob resolution, we should only pick up files with provided extensions. But since you are not passing in a glob, but an actual file, glob resolution does not occur, so ext is ignored completely. This is working as designed.

P.S. You don't need to pass ext: '.js'. ESLint always assumes that .js is passed in.

[monolithed]

let lint = new CLIEngine({ extensions });

let files = execSync('git diff --relative --name-only --diff-filter=AM HEAD', {
	encoding: 'utf8'
});

files = files.split(/\n/);

files = files.filter(file => {
	let { ext } = path.parse(file);

	return file.trim() && extensions.includes(ext);
});

let report = lint.executeOnFiles(files);

Not so comfortable for me :(
Is there any chance to change this behaviour?

[ilyavolodin]

We definitely can't change this behavior as it would be a major breaking change that would affect a lot of users out there. We could possibly add another flag for what you are describing. We would need teams opinion on this. But from my perspective, this seems a bit too edge-casey for my taste. This behavior has been around for 3 years now, and we haven't seen too many complains/requests for it, which is telling me that very few people need something like that. We usually try to avoid adding situational feature to ESLint that would only affect a few people.

[platinumazure]

I agree that it might not be worth doing a breaking change for this-- if, in fact, this would be a breaking change.

Here's how I understand the behavior of this option-- let me know if I'm wrong:

• With directories: Convert the directory name to a glob pattern, execute the glob, then apply an extension filter on the results.
• With filenames: Do nothing. Thus, more files are linted than the user might have intended when specifying --ext in the first place.
• With globs: Do nothing, because the glob pattern should have an extension on the end.

If I'm understanding the requested change, the goal is to have --ext also run an extension filter on the list of filenames. I believe we could do that without breaking the other cases. I agree that it should still be a semver-major change simply because users who have specified --ext in their build scripts (without it doing anything) may need to change their build scripts. But I don't think the impact is as serious as @ilyavolodin has suggested-- unless I'm missing something in my understanding of how the option currently works.

Arguments in favor of making this change:

• Better integration with CLIEngine when working with a list of files that might not all match the extension (glob patterns are not always sufficient, as demonstrated in the OP's case)
• Better integration with shells that are eager to expand globs (we would no longer need to tell people to quote their glob patterns)

That said, since there is a workaround, I'm not strongly in favor of making the change. I just think it's less "breaking" than originally thought.

[monolithed]

@ilyavolodin, @platinumazure thanks for your explanation. I see what you mean. Please close this issue if you see fit.

[nzakas]

Yeah, I don't think this is a big enough use case that we should implement a change. Maybe there's something we can do in the docs to explain this more clearly?