Linting doesn't work on Windows when node_modules is present in folder

[filipesilva]

What version of ESLint are you using?
v2.6.0
What parser (default, Babel-ESLint, etc.) are you using?
default
Please show your full configuration:

{
    "rules": {
        "semi": [
            2,
            "always"
        ]
    }
}

What did you do? Please include the actual source code causing the issue.

filipe.silva@DESKTOP-7ND6T3R MINGW64 /E/sandbox/eslint-test
$ node -v
v4.2.1

filipe.silva@DESKTOP-7ND6T3R MINGW64 /E/sandbox/eslint-test
$ npm -v
2.14.7

filipe.silva@DESKTOP-7ND6T3R MINGW64 /E/sandbox/eslint-test
$ eslint -v
v2.6.0

filipe.silva@DESKTOP-7ND6T3R MINGW64 /E/sandbox/eslint-test
$ ls -la
total 10
drwxr-xr-x 1 filipe.silva filipe.silva  0 Apr  4 12:50 ./
drwxr-xr-x 1 filipe.silva filipe.silva  0 Apr  4 12:36 ../
-rw-r--r-- 1 filipe.silva filipe.silva 89 Apr  4 12:37 .eslintrc.json
-rw-r--r-- 1 filipe.silva filipe.silva 11 Apr  4 12:38 test.js

filipe.silva@DESKTOP-7ND6T3R MINGW64 /E/sandbox/eslint-test
$ cat .eslintrc.json
{
    "rules": {
        "semi": [
            2,
            "always"
        ]
    }
}

filipe.silva@DESKTOP-7ND6T3R MINGW64 /E/sandbox/eslint-test
$ cat test.js
var a = 1

filipe.silva@DESKTOP-7ND6T3R MINGW64 /E/sandbox/eslint-test
$ eslint ./**/*.js

E:\sandbox\eslint-test\test.js
  1:10  error  Missing semicolon  semi

✖ 1 problem (1 error, 0 warnings)


filipe.silva@DESKTOP-7ND6T3R MINGW64 /E/sandbox/eslint-test
$ mkdir node_modules

filipe.silva@DESKTOP-7ND6T3R MINGW64 /E/sandbox/eslint-test
$ cp test.js node_modules/test.js

filipe.silva@DESKTOP-7ND6T3R MINGW64 /E/sandbox/eslint-test
$ eslint ./**/*.js

filipe.silva@DESKTOP-7ND6T3R MINGW64 /E/sandbox/eslint-test
$

What did you expect to happen?
I expected that running eslint ./**/*.js the second time would show the same result as the first time.
What actually happened? Please include the actual, raw output from ESLint.
Nothing was shown when running the command a second time.

This was run on a win10 machine using githbash.

[ilyavolodin]

node_modules and bower_components are ignored by default by ESLint. If you would like to lint those, you need to un-ignore them in .eslintignore files. Take a look at this issue #5410 for more information.

[filipesilva]

I understand that happens, but in my case I still had a file with lint errors outside the node_modules directory, I simply made a copy and put it inside the dir. Linting should still have shown the errors for the original file.

[ilyavolodin]

Ah. I see. Sorry, I didn't notice cp. I'm not 100% sure if ./**/*.js should include ./test.js. Theoretically ./**/ means any directory in the current folder, and as ./tests.js is not in the directory, it might be bypassed by globbing. @alberto @IanVS is this behaving correctly?

[filipesilva]

I suppose it should, because initially the same command caught errors in it:

filipe.silva@DESKTOP-7ND6T3R MINGW64 /E/sandbox/eslint-test
$ cat test.js
var a = 1

filipe.silva@DESKTOP-7ND6T3R MINGW64 /E/sandbox/eslint-test
$ eslint ./**/*.js

E:\sandbox\eslint-test\test.js
  1:10  error  Missing semicolon  semi

✖ 1 problem (1 error, 0 warnings)

[alberto]

Thanks @filipesilva for the detailed report!

I was able to reproduce this on a mac too.

It's not directly related to node_modules I think:

$ mv node_modules foo

$ eslint ./**/*.js

/Users/alberto/projects/oss/sandbox-5780/foo/test.js
  1:10  error  Missing semicolon  semi

✖ 1 problem (1 error, 0 warnings)

Note it's erroring for foo/test.js but not for ./test.js

[alberto]

Also note eslint . produces the expected output (also with a node_modules folder):

$ eslint .

/Users/alberto/projects/oss/sandbox-5780/foo/test.js
  1:10  error  Missing semicolon  semi

/Users/alberto/projects/oss/sandbox-5780/test.js
  1:10  error  Missing semicolon  semi

✖ 2 problems (2 errors, 0 warnings)

[platinumazure]

I think the correct glob syntax is **/*.js (I believe we replace . with **/*.js somewhere in CLIEngine).

./**/*.js would look in subdirectories of . only; but with node_modules being ignored by default, that would result in no linting.

I'm not sure why ./**/*.js with no subdirectories available would result in a clean linting run, though. I would expect no files to be linted.

[alberto]

@platinumazure I tried that and it doesn't work either.

[filipesilva]

I can confirm that estlint . gives the expected result. This pattern doesn't allow me to filter for only .js files though.

I tried with eslint **/*.js and did not get anything.

[platinumazure]

@alberto @filipesilva My mistake, then. It seems pretty likely that we have a bug.

[alberto]

@filipesilva eslint filters for .js file extension by default.

[filipesilva]

Ah that is great to hear! I tried using eslint . with a well configured .eslintignore on the main project I had issues in, and that worked well.

Thank you!

[ilyavolodin]

Are we handling patterns starting with . correctly now? I think there used to be a bug in --init where anything starting with dot would be ignored. Since we merged logic for glob unwrapping between init and CLI, maybe we have that bug in CLI now?

[IanVS]

@ilyavolodin the bug in --init should be fixed. Are you referring to #4828 (comment) perhaps?

[IanVS]

I think I see where you're going with this, and it's totally possible. Maybe this line needs to be changed to:

addPattern(this.ig.default, [".*", "!../", "!./"]);

My previous assumption for why the final "!./" would not be necessary is I expected it to be stripped out as part of our path normalization. It's worth exploring at least.

[ilyavolodin]

@IanVS That sounds like a possible fix. @alberto Since you were able to reproduce this issue, could you try and see if the fix that @IanVS suggested corrects this issue?

[alberto]

@ilyavolodin @IanVS It doesn't

[alberto]

Ok, after digging into this, I don't think it is a bug.

If you use a glob in the command line, it turns out the shell with expand the globs (at least on UNIX).

So eslint ./**/*.js generates this process.argv:

[ '/Users/alberto/.nvm/versions/node/v5.9.1/bin/node',
  '/Users/alberto/.nvm/versions/node/v5.9.1/bin/eslint',
  './foo/test.js' ]

Note this differs from node's glob expansion, in that it will only look match js files in one-level-deep directories (it won't match ./test.js nor foo/bar/test.js).

The proper way to pass an unexpanded glob in the commandline is by quoting it:

$ eslint '**/*.js'

/Users/alberto/projects/oss/sandbox/issue5780/foo/test.js
  1:10  error  Missing semicolon  semi

/Users/alberto/projects/oss/sandbox/issue5780/test.js
  1:10  error  Missing semicolon  semi

✖ 2 problems (2 errors, 0 warnings)

[platinumazure]

I assume the reason you're using single quotes is to ensure the shell won't
interpret the quotes, so that a glob strong with quotes is passed to node
glob?
On Apr 5, 2016 11:53 AM, "alberto" notifications@github.com wrote:

Ok, after digging into this, I don't think it is a bug.

If you use a glob in the command line, it turns out the shell with expand
the globs http://wiki.bash-hackers.org/syntax/expansion/globs (at least
on UNIX).

So eslint ./*/.js generates this process.argv:

[ '/Users/alberto/.nvm/versions/node/v5.9.1/bin/node',
'/Users/alberto/.nvm/versions/node/v5.9.1/bin/eslint',
'./foo/test.js' ]

Note this differs from node's glob expansion, in that it will only look
match js files in one-level-deep directories (it won't match ./test.js
nor foo/bar/test.js).

The proper way to pass an unexpanded glob in the commandline is by quoting
it:

$ eslint '*/.js'

/Users/alberto/projects/oss/sandbox/issue5780/foo/test.js
1:10 error Missing semicolon semi

/Users/alberto/projects/oss/sandbox/issue5780/test.js
1:10 error Missing semicolon semi

✖ 2 problems (2 errors, 0 warnings)```

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#5780 (comment)

[alberto]

Yes, by quoting it, the argument is passed as a literal.

$ eslint '**/*.js'
[ '/Users/alberto/.nvm/versions/node/v5.9.1/bin/node',
  '/Users/alberto/.nvm/versions/node/v5.9.1/bin/eslint',
  '**/*.js' ]

[filipesilva]

Would just like to say thanks for all the help. You found a solution for my issue, got to the bottom of it and even added docs. Very cool. Cheers!