I noticed this when making changes to my .eslintrc.js file. ESLint errors will not show up in hidden files (files prefixed with a dot).
If I have a file, test.js, with ESLint errors, they are displayed in my editor with a squiggly underline, and in the problems tab. If I re-name the file to .test.js, the VS Code ESLint extension seems to ignore it completely.
This is standard eslint behavior. If elint is executed in the terminal you get:

I will close the issue since the extension tries to stick with the normal ESLint behaviour.
Reopening: we do should make sure that the warning is shown in the problem panel. But we will still not validate the file.
Isn't the underlying problem that the .eslintignore is not honored? See https://github.com/eslint/eslint/issues/8429#issuecomment-355967308 – hidden files (leading .) can be opted into by negated globs.
@leoselig the .eslintignore` is honored. If you think otherwise can you provide me with a GitHub repository I can clone that demos what you are seeing?
@dbaeumer Yes, I can do. And it's good that I did because I discovered that it's specifically related to nested or non-top-level .eslintignore setups.
See my repro repo (_*pun*_) here: https://github.com/leoselig/repro-vscode-eslint-ignorefiles
I have the same issue, but for me an entire dot prefixed directory is not being linted despite being in the .eslintignore
@leoselig this is actually expected since eslint ignores them as well if you run the command from the workspace root .\node_modules\.bin\eslint --ext=js .\packages\pkg1\
ESLint: 5.9.0.
All of the files matching the glob pattern ".\packages\pkg1\" are ignored.
If you don't want to lint these files, remove the pattern ".\packages\pkg1\" from the list of arguments passed to ESLint `.
If you do want to lint these files, try the following solutions:
* Check your .eslintignore file, or the eslintIgnore property in package.json, to ensure that the files are not configured to be ignored.
* Explicitly list the files from this glob that you'd like to lint on the command-line, rather than providing a glob as an argument.
The reason for that is that the eslint ignore file look up is not relative to the file it is relative to the current working directory in ESLint. So you need to tell the ESLint extension in this setup what the working directories are. If you add this to the settings:
{
"eslint.workingDirectories": [
{ "directory": "packages/pkg1", "changeProcessCWD": true }
]
}
The file is validated correctly

@dbaeumer Got it. Wow, this is messy. So for our case the conflict actually is that on CI/via our scripts we are running ESLint in each workspace package (monorepo) but in VSCode it is a single ESLint instance running on the root.
Thanks for clarifying. We'll try to figure something out.
@leoselig simply configure the "eslint.workingDirectories" for each workspace package and it should work as expected.
@dbaeumer I should have been more clear about what issue I still have with this. We are working in quite a large mono repository where packages tend to come (and even go) quite frequently. Therefore I dislike maintaining a list of
eslint.workingDirectories but a glob does not seem to work at the moment.
Why such complicated logic? Why not just respect .eslintignore for the current directory and sub-directories? I mean currently you cannot open a folder with many sub-folders without maintaining this list.
It's probably worth opening this on https://github.com/eslint/eslint. The logic appears to be here:
Just as a pointer: the upcoming ESLint version has two improvements here:
/packages/*/). So for large mono repositories you very likely only need one entry :-)Since quite some time there is a setting "eslint.onIgnoredFiles": "warn" to enable / disable the warning in the extension.
Most helpful comment
This is standard eslint behavior. If elint is executed in the terminal you get:
I will close the issue since the extension tries to stick with the normal ESLint behaviour.