Vscode-eslint: How to lint all files in project?

[empz]

I noticed ESLint only shows errors of files you've opened. Is there a way to force it to scan all files in the project?

[dbaeumer]

Currently not. However we were thinking about adding that support.

[egamma]

@emzero - @dbaeumer is correct, but what you can do today is to create a task that runs eslint across all files.

[oshalygin]

Is the challenge reducing the overhead in constantly linting all files in the solution?

We can always run eslint from the command line but of course it would be ideal if all files were automatically linted as we work through a solution.

[johntmyers]

Would be nice for Python too. For example if I change the name of a module, nothing re-lints, etc until some code is changed and a file is re-saved.

[cesaraaron]

I need this badly (I come from standard and the plugin for vscode does this by default)
Any news?

[oshalygin]

Willing to help if someone can give direction on where to even start.

[llozesdome]

I understand that linting the whole project all the time could damage the performance. A dedicated action that could be run on demand would still be great.

[egamma]

Here is an example for how to do this for eslint using Tasks https://github.com/Microsoft/vscode-eslint/blob/master/eslint/README.md#using-the-extension-with-vs-codes-task-running

[avizov]

the link is broken... can you please check?

[dbaeumer]

https://github.com/Microsoft/vscode-eslint/blob/master/README.md#using-the-extension-with-vs-codes-task-running

[janaagaard75]

This answer here on Stack Overflow might also be helpful: https://stackoverflow.com/q/41702815/37147.

[avizov]

Just to verify, the proposed "task" solution is it from vscode client side (an ability to run tasks in vscode editor)?
In our case we are not using vscode editor as our client but we are using some another editor tool. Is there option to run task using LSP protocol?

[i328638]

I created PR #323 for prviding a new project level diagnostics mode.
I used the existing initializationOptions: any which is part of the initialization parameters.
I added there a new property projectValidation that if true, diagnostics are maintained on the whole project level and not only for opened documents.
I tried to cover the changes in document life cycle for this new mode.
Please review this solution.

[renato]

I'm using a custom task to extract the eslint errors/warnings but the default $eslint-stylish problemMatcher doesn't add the "eslint" owner to the problems, so the [eslint] prefix is only added after I open a file, and when I close it the eslint problems are removed.

I understand that the errors are currently being cleared on close (#306) but is there a current workaround to both situations?

EDIT: I just checked and it's using the eslint owner but for some reason all messages are missing the prefix.

[dbaeumer]

This is a bug on the VS Code side we are aware of.

[tvvignesh]

Hi guys. Any plans on making this available? Is it in the roadmap?

[dbaeumer]

I started to work on this last week but nothing finished yet. The branch is https://github.com/Microsoft/vscode/tree/dbaeumer/47386

[stavalfi]

Hi, is there any progress on this issue?

Thanks in advance!!

[dbaeumer]

No, nothing has happened. The original bug in VS Code https://github.com/Microsoft/vscode/issues/47386 got fixed for TS but ESLint doesn't profit from this.

I gave feedback on the PR however I am not sure if this should really be built into the extension or better be handled as a task.

[stavalfi]

shouldn't it be on a different issue than Microsoft/vscode#47386?

[hadim]

Any news on this?

[techsin]

+1

[dbaeumer]

I opened https://github.com/Microsoft/vscode/issues/61140. The work for this is still on branch https://github.com/Microsoft/vscode/tree/dbaeumer/47386

[joelricci]

There should at least be an option in the Command-Palette to lint entire project/directory.

[dbaeumer]

There is a setting since a while that contribute a lint task which can then be executed from the Terminal -> Run Task menu. The setting is "eslint.provideLintTask": true.

[David-Else]

@dbaeumer provideLintTask seems to be linting .js files, but not .ts files... can we get a task that does that? The .js files need to be ignored. I have this in settings already:

  "eslint.validate": [
    "javascript",
    "javascriptreact",
    {
      "language": "typescript",
      "autoFix": true
    },
    {
      "language": "typescriptreact",
      "autoFix": true
    }
  ],

  "files.exclude": {
    "**/*.js": { "when": "$(basename).ts" },
    "**/*.js.map": true
  },



md5-e178e17df60a67c9d5c5ba23eafc9c49



eslint: lint whole folder (.js files)
eslint: lint whole folder (.ts files)

Thanks!

[dbaeumer]

@David-Else the task actually doesn't have any filter. All it does is calling .\node_modules\.bin\eslint . How do you lint all ts files from the command line right now?

[David-Else]

@dbaeumer I use:

"eslint": "eslint --cache --no-color --ext .ts src/ test/"

I was wondering, did you try the --cache option for linting then entire workspace? It looks like it should speed things up, but I have not tested it with/without myself.

[dbaeumer]

Looks like . defaults to .js. So the task might not work for other file types either. One idea would be to use the validate setting to understand which extensions to validate.

[dbaeumer]

To implement this we however need API to map a language ID to the file extensions. Seems to not be available right now.

[mauron85]

To implement this we however need API to map a language ID to the file extensions. Seems to not be available right now.

@dbaeumer I've tried to add .ts extensions in settings.json, but it doesn't seems to be working with provideLintTask.

{
    "eslint.options": {
        "configFile": ".eslintrc.js",
        "extensions": [".ts", ".tsx", ".js", ".jsx"]
    },
    "eslint.provideLintTask": true,
    "eslint.validate": [
        "javascript",
        "javascriptreact",
        {
            "language": "typescript",
            "autoFix": false
        },
        {
            "language": "typescriptreact",
            "autoFix": false
        }
    ]
}

EDIT: Also not sure about configFile option. Does it support configuration from .js file (instead of json)?

EDIT2: It seems that eslint.options are currently ignored (at least by provideLintTask). Console output shows that eslint is always started without any parameters:

Executing task: node_modules/.bin/eslint . <

[mattapperson]

@mauron85 seeing the same issue as you, can't seem to get the task to find any files

[dbaeumer]

It seems that eslint.options are currently ignored (at least by provideLintTask). Console output shows that eslint is always started without any parameters:

This actually a good point and these should be honored when running the lint task. I opened https://github.com/microsoft/vscode-eslint/issues/682 which would be a good candidate for a PR :-)

[dbaeumer]

There is now eslint.lintTask.options which allows to specify the command line passed to the external lint task.

[obendev]

Hey, I'm getting a lot of 'niceFunction' is not defined.eslint(no-undef)-errors. But niceFunction is defined in another file of my project.
When this feature gets implemented, would this mean eslint also 'understands' that there are other files to scan for?

[agwells]

Hey, I'm getting a lot of 'niceFunction' is not defined.eslint(no-undef)-errors. But niceFunction is defined in another file of my project.
When this feature gets implemented, would this mean eslint also 'understands' that there are other files to scan for?

What you're describing is unrelated. If niceFunction is declared in "file A", then referencing it in "file B" is a mistake unless:

• You are importing it into "file B" via an import or require, in which case eslint will not complain about it being undefined
• OR You've made niceFunction into a global variable, in which case you need to specifically tell eslint that it's a global variable via a /*global ... */ comment or a globals config. See: https://eslint.org/docs/rules/no-undef#rule-details

The reason you have to declare globals explicitly, is because ESLint actually only analyzes each file by itself, in isolation. That's true whether or not you're using this VS Code plugin, and whether or not you're linting one file or a batch of files. Each file is analyzed and judged on its own, then its contents are forgotten and it moves on to the next file.

[telmotrooper]

If you only want to check if there are linting errors in the project but not to auto-fix them (e.g. to use in a CI/CD environment so you won't allow PRs with linting errors to pass) you can use:

eslint src --ext .ts,.tsx (from package.json)
or
npx eslint src --ext .ts,.tsx (from command line).

These commands are for TypeScript files, but you can exchange those for .js and it should work fine.

[OnkelTem]

So for 4 years they haven't added this crucial feature.
WebStorm does it out of the box.

[dbaeumer]

To be clear about this:

• the support for linting the whole project is implemented using tasks
• linting a whole project requires a user actions (like triggering a build)

Incrementally linting the whole project is not implemented due to the lack of support in ESLint for it. I will look into supporting this when ESLint has support for it.

[OnkelTem]

Sorry, I mixed things up a bit: I thought this repository and its issue queue - is the original VSCode repo, while it's actually a ESLint plugin project. Of course, not everything is under your control when you basically write a plugin.

That's said - maybe it's worth closing this topic then? Because keeping it open will continue inciting hurrying fellows like me to just skip the whole discussion trying to find an all-answering post somewhere at the end of it.

[mika76]

• the support for linting the whole project is implemented using tasks

The problem with this is that it's totally separate from the ide and does not show the errors in the errors view.

Incrementally linting the whole project is not implemented due to the lack of support in ESLint for it. I will look into supporting this when ESLint has support for it.

Could you be more specific here? Is there an outstanding error on eslint side that can be referenced or do you just mean in general? Could the extension not lint each changed file separately and concat the errors or something like that?

maybe it's worth closing this topic then?
Please don't. It's still a wanted feature by a lot of people.

[dbaeumer]

The problem with this is that it's totally separate from the ide and does not show the errors in the errors view.

When the task is run from within VS Code (see setting eslint.lintTask.enable) and the task gets executed using Terminal > Run Task all the errors should show up in the errors view.

The ESLint library has no support for incremental liniting. That means if a project has 100 files if you want to lint the whole project you need to relint all 100 files.

Currently only the opened changed files are linted. We experimented with linting all open files but that causes other confusions since people where assuming we are doing a dependency linting (which we actually can't do). So we stayed away from it.

Since ESLint now has lint rules across files the right fix is to ask ESLint to add a incremental / watch mode like compilers do (see TypeScript compiler for an example). Trying to do this outside will always result in strange behavior or a huge performance impact.

[mika76]

@dbaeumer Thanks for the info.

Is there maybe an issue logged on the eslint project that can be referenced here to keep watch of?

Edit: I can't seem to find any that mention the words "incremental" or "watch"...

[dbaeumer]

@mika76 I actually don't know.

[mika76]

Ok I've posted one just to try move the process along. Let's see what they have to say...

[mika76]

@dbaeumer There seem to be some questions there which I can't answer - could you maybe take a look?

[dbaeumer]

@mika76 Done.

[baconcheese113]

Having problems getting the task to run in my monorepo. My folder structure looks like:

📦root
 ┣ 📂.vscode
 ┃ ┗ 📜settings.json
 ┣ 📂client
 ┃ ┗ 📂src
 ┃ ┗ 📂node_modules
 ┃ ┗ 📜.eslintrc
 ┃ ┗ 📜package.json (eslint dependency)
 ┣ 📂server
 ┃ ┗ 📜index.js
 ┗ 📜package.json

Get this error when trying to run eslint: lint whole folder

settings.json

{
  "editor.formatOnSave": true,
  "eslint.debug": true,
  "eslint.lintTask.enable": true,
  "editor.codeActionsOnSave": {
    "source.fixAll": true
  },
  "editor.codeActionsOnSaveTimeout": 5000,
  "eslint.workingDirectories": ["./client"]
}

client/package.json script is:
"lint": "eslint ./src --ext .js"

npm run lint works perfectly from the /client directory

[dbaeumer]

@baconcheese113 have you tried to customize this using the eslint.lintTask.options setting.

[baconcheese113]

Yea, tried that and specified the .eslintrc location...but the issue was probably needing to specify the eslint bin location. Also created a custom task and got it to actually start up (according to the terminal) but it didn't do anything...

{
    // See https://go.microsoft.com/fwlink/?LinkId=733558
    // for the documentation about the tasks.json format
    "version": "2.0.0",
    "command": "cmd", // for windows "command": "cmd"
    "args": [
        "-c"
    ], // for windows "args": ["/C"]
    "tasks": [
        {
            "label": "eslint",
            "args": [
                "client/node_modules/eslint/bin/eslint.js ./src --ext .js" // To use locally installed eslint,  ./node_modules/eslint/bin/eslint.js .
            ],
            "problemMatcher": [
                "$eslint-stylish"
            ]
        }
    ]
}

Finally gave up and moved my .eslintrc, .eslintignore and eslint deps to my root directory. client is a create-react-app and has it's own eslint packages included. So now with these settings I'm still unable to get auto-fixing working in client but it's working in server 🤔 Any thoughts?

{
  "editor.formatOnSave": false,
  "eslint.lintTask.enable": true,
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": true,
  },
  "eslint.validate": ["javascript", "javascriptreact", "typescript", "typescriptreact"],
  "editor.codeActionsOnSaveTimeout": 5000,
}

[dbaeumer]

Do you have a GitHub repository I can clone?

[baconcheese113]

Here ya go https://github.com/baconcheese113/god-help-me-lint
Explained it a bit in the readme, I'm not using the prettier extension since that seems to mess things up.

[dbaeumer]

Can you please provide additional steps to reproduce the problem.

If I try to lint the client in the terminal ./node_modules/.bin/eslint client/src/index.js I get

Oops! Something went wrong! :(

ESLint: 6.8.0.

ESLint couldn't find the config "react-app" to extend from. Please check that the name of the config is correct.

The config "react-app" was referenced from the config file in "/home/dirkb/Projects/mseng/VSCode/Playgrounds/bugs/god-help-me-lint/client/package.json".

If you still have problems, please stop by https://gitter.im/eslint/eslint to chat with the team.

[baconcheese113]

@dbaeumer Sorry, didn't try to run it through the terminal since I could already tell eslint was working on some files (but not the exhaustive-deps rule)....

I think my issue is actually due to this https://github.com/microsoft/vscode-eslint/pull/814#issuecomment-593678010 Currently I use [email protected] at work and wasn't aware of the big change between it and 2.5.1 which prevents auto-fixing of the rule I was hoping for.

Do you know any ways to enable auto fixing for suggestions?

[dbaeumer]

Suggestions by definition can't be autofix. But they will show up as a possible fix in the code action menu (when you click on the light bulb). Requires the latest version of the ESLint extension.

[mika76]

So @dbaeumer to get the original discussion back on track - what are your thoughts on a full-project-lint going forward? Do you think the caching feature would work/help?

[dbaeumer]

@mika76 from the experiments I did I got the impression that they caching feature will not help a lot since you still need to validate all files in the project.

I still think that a task triggered by a user is currently the right approach for this.

[mbomb007]

If you want to lint the whole workspace set eslint.lintTask.enable to true and the extension will also contribute the eslint: lint whole folder task. There is no need anymore to define a custom task in tasks.json.

Source: https://github.com/Microsoft/vscode-eslint/blob/master/README.md#using-the-extension-with-vs-codes-task-running

[DanTup]

@dbaeumer

Currently only the opened changed files are linted. We experimented with linting all open files but that causes other confusions since people where assuming we are doing a dependency linting (which we actually can't do). So we stayed away from it.

Does this mean we're not likely to see this automatic whole workspace linting anytime soon? I was trying to migrate from tslint to eslint because I was getting warnings about it being deprecated, but just noticed I'm not seeing the errors anymore without files open. With tslint, I did get this (I'm not sure exactly through what mechanism - it might be that webpack is running onFolderOpen in watch mode and using ts-webpack-watch?).

[dbaeumer]

To my knowledge the TSLint extension only validated the open files as well (@egamma can you confirm that). So if the whole workspace got linited it was very likley through a task which is also support in ESLint.

[DanTup]

I do have tasks that run on folderOpen (tsc --watch and webpack --watch) with the $ts-webpack-watch and $tsc-watch problem matchers which I suspect were doing this (the $ts-webpack-watch problem matcher is coming from the eamodio.tsl-problem-matcher extension) but they're all still running after moving to eslint. I couldn't find any info about whether (and if so how) this should work though 😟

[daiky00]

wow this was open 4 years ago and is not resolved O.o

[dbaeumer]

@daiky00 have you use the setting eslint.lintTask.enable

[aFcFzF]

npx tsc --noEmit

[ooyyloo]

I want to lint all files of the project when opening the project folder, and then show errors on opened files. Is this possible using APIs provided?

[Domiii]

Workaround

Since this is maybe low priority for the team for now, here is a possible workaround.

While we cannot easily add "all problems in project" to the PROBLEMS tab, at least we can automatically open "all problematic files" in the editor:

1. I have a monorepo with several packages, each having an src folder I want to lint.
2. My eslint command looks like this: npx eslint **/src/**/*.js
3. We can simply grep all problematic files like this: npx eslint **/src/**/*.js | grep ^[\\w/].*\\.js
   
   
   
   • Why does this work? Because for every line of output:
     
     
     
     
     
     • if the line is a file: starts with a character (on Windows) or a slash (any other OS)
     
     
     
     • if the line is an error: starts with spaces
     
     
     
   
   
4. We can then open all problematic files in VSCode using the code command line tool: code $(npx eslint **/src/**/*.js | grep ^[\\w/].*\\.js)

I ended up adding the 3 following scripts to my package.json:

"eslint": "npx eslint **/src/**/*.js",
"eslint:files": "npx eslint **/src/**/*.js | grep ^[\\w/].*\\.js",
"eslint:files:open": "code $(npx eslint **/src/**/*.js | grep ^[\\w/].*\\.js)"

Hope that helps :)