Does not respect nested eslintignore files

[jdforsythe]

The plugin does a good job of working up the tree to find the most local configuration file, but it doesn't do the same with .eslintignore files.

Consider the project layout:

inner/
  .eslintignore
  .eslintrc.json
  test.js
.eslintignore
.eslintrc.json
test.js

Root directory files

/.eslintrc.json

{
  "rules": {
    "eqeqeq": [ "error", "always" ]
  }
}

/.eslintignore

inner/*

/test.js

if (0 == 1) console.log('what?!');

/inner files

/inner/.eslintrc.json

{
  "rules": {
    "eqeqeq": ["warn", "always"]
  }
}

/inner/.eslintignore

!test.js

/inner.test.js

if (0 == 1) console.log('what?!');

If you remove the .eslintignore files, you will correctly get an error in /test.js and a warning in /inner/test.js.

If you add just the /.eslintignore file, it ignores the inner folder. I think the expected behavior would be to reset the "ignore" blobs at the same root as the .eslintrc.json file is found. That's what I had expected anyway.

So I added the /inner/.eslintignore file and it does not override the root ignore blobs. This still produces no warning in the /inner/test.js file.

[jdforsythe]

Possibly related to #110?

[jdforsythe]

This is necessary to us because we have node code in several directories off the root that get linted using the main configuration. But in one of the directories we also have client-side code that uses a completely different config, and in another, test code that uses yet another config. Different ignore blobs are necessary in these locations, as well.

I think the proper behavior would be to crawl up the tree to find the first .eslintignore file and use that.

[dbaeumer]

Actually the extension doesnät crawl the tree by itself. I simply call into the ESLint node API documented here http://eslint.org/docs/developer-guide/nodejs-api#executeontext. Need to understand why this doesn't work.

@jdforsythe one question: if you run eslint from the command line everything works as expected in that setup. Right?

[desmondmorris]

+1 - This would be very helpful

[jdforsythe]

Sorry for the delay, @dbaeumer. To answer the question - it depends. If you run eslint from the root directory, it behaves the same as the extension, only bringing back the one error in /test.js and ignoring the inner/* directory. However, if you run eslint from inside the /inner directory, it reads the .eslintignore and .eslintrc.json files from there, showing the error in /inner/test.js.

[dbaeumer]

Fixed in next update. See comments in #97

[dbaeumer]

Reopening. I need to revert the fix since it broke #198

[dbaeumer]

OK. After thinking about this again it is nothing the extension can fix without letting the user configure this. As @jdforsythe pointed out and my testing confirmed the behavior of eslint reading the .eslintignore file depend on the directory that eslint as started from. To reiterate:

To answer the question - it depends. If you run eslint from the root directory, it behaves the same as the extension, only bringing back the one error in /test.js and ignoring the inner/* directory. However, if you run eslint from inside the /inner directory, it reads the .eslintignore and .eslintrc.json files from there, showing the error in /inner/test.js.

So I need to let the user defined which cwd directory to choose when linting which files.

[dbaeumer]

I read through the documentation of ESLint again and ESLint itself (on the command line) doesn't support merging .eslintignore files. From the doc:

Only one .eslintignore file can be used at a time, so .eslintignore files other than the one in the current working directory will not be used.

What I added for ESLint now is support for specifying working directories to better control which .eslintignore file is choosen. The syntax is as follows:

	"eslint.workingDirectories": [
		"./inner"
	]

So will choose the inner directory as the working directory for all files linted that are in the inner directory or in one of its subdirectories.

Given how ESLint is working this is all I can do.

[dbaeumer]

Delivered in 1.2.5