Feature Request: Show all errors and warnings in project for all JavaScript and TypeScript files, not just opened ones

[kevinjreece]

I am using VS Code on a project at work that has hundreds of files and many layers of nested sub-directories. I frequently make changes that break many files, such as changing the call signature of a commonly used method. Since the project is entirely typescript, it is useful to be able to open the "Problems" view and see the errors and warnings my change caused in the files I have open. However, because of the size of the project, I still need to go to my terminal and run our own make commands to see the list of problems. I then need to perform the fun dance between my terminal and VS Code, searching for the right line in the right file before I can fix the problem.

What I need is a way to tell the "Problems" view to show me all errors and warnings across all open and closed files in my project. This would allow me to see all problems in a single list and quickly click through and fix them.

[Bardimaswift]

When?

[mattwills8]

The 'accepted' solution above works, but some of the fields are deprecated.

{
      "label": "Watch TS Errors",
      "type": "shell",
      "command": "tsc",
      "args": ["-w", "-p", ".", "--noEmit"],
      "isBackground": true,
      "problemMatcher": "$tsc-watch"
}

Works for me.

Also see https://code.visualstudio.com/docs/editor/tasks for creating tasks.json file if you dont have one yet

[OliverJAsh]

Is it possible to disable VS Code's built-in TS server when running tsc as a build task like this? The reason I ask is because otherwise we get two sets of errors: those from the built in TS server and those from the task, and sometimes they are out of sync.

[fantaclaus]

The IDE is broken and unusable for work on Typescript projects. So I have to stick to the version 1.28.2 and disable updates.

Strange, but it worked somehow before. What's happened? And when will it work again? Already an year passed and there is no sign of change...

[kanlukasz]

3 years for a feature which others IDE offer.... NNNNICCCEEEEEEEEEEEEEE

Remember that VSCode is not an IDE. It's something beetwen Editor and IDE. Anyway, I hope they do it

[mjomble]

what a bullshit

For a bit of perspective:

Microsoft made some software and gave it away for free. This software is helpful to millions of people who are grateful for it. Microsoft is not forcing you to use this software.

You are angry at them for giving you something for free because it is not as perfect as it theoretically could be.

[asfernandes]

Also, he uses that same "IDE"'s language, and the IDE is open source and accept pull requests...

[sillero]

I've been watching this for a long time now, still waiting for a better way to track errors and warnings, and I've been using it since public launch.

That being said, VS Code is in my opinion undoubtedly the best IDE for JS/TS development - heck, it might even be the best MS product, second only to Github. There has definitely been improvements in features and performances, and the sheer amount of extensions makes me very happy. Yes, the docs could be better, but you can say that about every tech documentation out there.

I'm sure the VS Code team is constantly working hard on bringing better tooling and integrations.

And I believe we can still ask for new features or keep bumping this one up in a polite manner.

[bscaspar]

Adding on to the workaround - It looks like there's now a pre-configured task to monitor the output of tsc -w. On a mac, Terminal -> Configure Tasks... -> tsc: watch - tsconfig.json. Then hit ctrl+shift+B and run the task.

[gradddev]

Three years later... Any news?

[genevpd]

In the middle of large-scale refactoring. I didn't realize that by closing all affected files I will no longer see all the errors :-(

[thinh105]

3 years and still open :dancer:

[caseyhoward]

I find the problems tab useless because of this so I never use it. Instead I run some command in the terminal that actually gives me what I need. For example, if I all compiler errors for the project I run tsc -w. I either want to see all the problems in my project or none. I don't care if a file happens to be open or not. It's irrelevant.

[fantaclaus]

Well, if it is so important for someone to see errors only for open files in Problems tab, let it be.

But could you please create another tab, say Build Output just like in Visual Studio.

This tab would show errors and warnings from the compiler as a simple one-line text and a double click on it would open the file and place the caret right on the line with the error.

Also F4/Shift-F4 shortcuts would be great to jump to next/prev error (but this is not so crucial)

Just clear this tab completely and fill it again after each compilation. That would be enough.

Or maybe someone could create an extension for this?

[ricklove]

I'm using an "Open Matching Files" extension to open all .ts files. It's a bit performance heavy, but at least it gets the job done.

[Artur2]

I think it's because of typescript language server is single-threaded and don't behave like C#'s compiler Still waiting for this feature, because sometimes I opening file and trying to find type by name using command palete with #, and nothing happen 😞

[mjbvz]

For those who wish to live on the edge, the next VS Code insiders build introduces a "typescript.tsserver.experimental.enableProjectDiagnostics" setting that enables experimental project wide error reporting

Note that this is not production ready! It has known perf issues for larger projects and may break your intellisense

If you experience a problem while using this setting, please open a new issue

[whatwg6]

For those who wish to live on the edge, the next VS Code insiders build introduces a "typescript.tsserver.experimental.enableProjectDiagnostics" setting that enables experimental project wide error reporting

Note that this is not production ready! It has known perf issues for larger projects and may break your intellisense

If you experience a problem while using this setting, please open a new issue

good job~

[RobbieGM]

Where might we be able to check on the progress of this feature? I am eagerly awaiting its addition to the standard edition of VS code when it's ready.

[maxpaj]

For those who wish to live on the edge, the next VS Code insiders build introduces a "typescript.tsserver.experimental.enableProjectDiagnostics" setting that enables experimental project wide error reporting

Note that this is not production ready! It has known perf issues for larger projects and may break your intellisense

If you experience a problem while using this setting, please open a new issue

Thank you all contributors to Visual Studio Code for your amazing work.

[spacesuitdiver]

For those who wish to live on the edge, the next VS Code insiders build introduces a "typescript.tsserver.experimental.enableProjectDiagnostics" setting that enables experimental project wide error reporting

How does this work with other linters?

[vdh]

I've had an issue where any time I enable "typescript.tsserver.experimental.enableProjectDiagnostics", the Typescript linter eventually goes down a rabbit hole of traversing node_modules and digging up hundreds of errors from distribution files, even when "exclude" in tsconfig.json contains "node_modules". I can't quite figure out how to debug this.

[martaver]

I also get the same effect as @vdh - my VSCode parses my entire node_modules folder, and runs eslint against each file.

My eslint/editor configuration is:

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

Seems like first order of business really should be that any file with node_modules in its path should be ignored, at least for on-save actions.

[blackfan23]

This is a much appreciated feature. I got the same behaviour as @Martaver @vdh . "Solved" it for now by adding the filters

!*node_modules, !*.vscode

to the terminal view. (only visually different). In case someone is interested in playing with this.

[martaver]

@blackfan23 seems a bit like sweeping the dust under a rug :D

[SupremeTechnopriest]

@Martaver Agreed. Something like:

"typescript.tsserver.experimental.enableProjectDiagnostics.ignores": [
  "**/node_modules/**"
]

would be ideal. Its kind of shitty to see over 1k problems on a project when there are actually 0.

[vdh]

@blackfan23 That's not an option, due to all the excess CPU churn caused by the nosedive into node_modules

[arisferyanto]

@vdh I set skipLibCheck to true in tsconfig and "problems" tab stopped showing errors from node_modules.

However, based on this stackoverflow thread, turning on this option degrades type checking. Appreciate if someone from VS code or typescript team can shed some light on the pros and cons of turning this option on.

[eladcandroid]

@mjbvz Works great! thanks! Can we execute "Fix all" for these errors with a one command?

[dmitryivashkin]

What about other languages, not Typescript? For example, I have hundreds of PHP files in the project and I can see problems reported by Intellephense extension for individual file, but what I really want is to run diagnostic for the entire workspace.

[vdh]

Yes this also causes issues where ESLint is doing the same nosedive into node_modules("ESLint: Failed to load config" as it trawls the directories in there). There really needs to be a blacklist or something instead of trying to patch this bug out per-linter.

[patroza]

Excluding the node_modules would be a no1 fix :)

[patroza]

This seems to work a boot, but - your millage may vary, and of course, no warranty:

Given you have typescript 3.9.2 in your package.json, and have selected that version from your workspace in VSCode:

1. https://www.npmjs.com/package/patch-package

2. : ./patches/typescript+3.9.2.patch

   diff --git a/node_modules/typescript/lib/tsserver.js b/node_modules/typescript/lib/tsserver.js
   index 2b6f035..ac6c9b4 100644
   --- a/node_modules/typescript/lib/tsserver.js
   +++ b/node_modules/typescript/lib/tsserver.js
   @@ -149353,7 +149353,7 @@ var ts;
                    return;
                }
                // No need to analyze lib.d.ts
   -                var fileNamesInProject = fileNames.filter(function (value) { return !ts.stringContains(value, "lib.d.ts"); }); // TODO: GH#18217
   +                var fileNamesInProject = fileNames.filter(function (value) { return !ts.stringContains(value, "lib.d.ts") && !ts.stringContains(value, "node_modules"); }); // TODO: GH#18217
                if (fileNamesInProject.length === 0) {
                    return;
                }

3. npm install or yarn

4. Restart VSCode

= profit?

[DanTup]

@mjbvz I tried enabling this, and I see pretty high CPU usage from the "Code Helper (Renderer)" process compared to when I turn it off. Does it seem likely this is related ("Renderer" in the process name suggests not, but I toggled it a few times). The project is not huge (it's https://github.com/Dart-Code/Dart-Code).

It doesn't last forever, but it spins my MacBook fans up enough that right now that I'd probably keep it off rather than on.

[vdh]

Has there been any investigations so far into why "typescript.tsserver.experimental.enableProjectDiagnostics" always dives into all the files inside node_modules, despite our various failed attempts at setting linter configs to avoid node_modules?

It's disappointing, because this potentially-awesome feature is completely killed by the excessive CPU churn caused by it iterating unwanted files & directories… 😢

[hi2u]

I've been seeing the same issues @vdh mentioned above with TypeScript errors from node_modules appearing in the PROBLEMS panel - wasn't sure whether to report a bug, or if it's just some mis-config issue I've caused.

I've tried various tsconfig.json settings like:

"exclude": ["node_modules", "./node_modules/*"],

I haven't quite figured out if there's a pattern to whether I see the issue or not. Some things I suspect might be/were happening:

• It seemed to randomly come and go, sometimes restarting vscode helped for a bit, but it would come back later.
• Appeared to affect some projects more than others.
• I'm not seeing the issue right now, so perhaps a recent update fixed something? I'm still running the Insiders edition.

Not entirely sure about the points above, could just be me being confused. Just adding another possibly relevant anecdote. If there's a few of us still seeing the issue in current versions, may be worth filing a new issue. Haven't done that yet seeing I'm not quite sure about any of it.

[enko]

I had the same problem and my solution in #90430 was to use typescript-tslint-plugin.

[vdh]

@enko TSLint has been deprecated in favour of ESLint since 2019, advocating a plugin for a deprecated linter is not a good solution to this issue.

[jgoux]

I had to disable typescript.tsserver.experimental.enableProjectDiagnostics because it made

"editor.codeActionsOnSave": {
    "source.fixAll.eslint": true
  }

extremely slow (2min to save a single file).

I also noticed random TS errors from node_modules, which were appearing / disappearing.

[samesfahani-tuplehealth]

There is a working workaround actually if you set your applyTo properly in tasks.

A full working task that will watch compile and report problems to the Problems pane even for files not currently in view is shown below:

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "tsc watch",
      "type": "shell",
      "command": "tsc",
      "isBackground": true,
      "args": ["--build", "--watch"],
      "group": {
        "kind": "build",
        "isDefault": true
      },
      "presentation": {
        "reveal": "never",
        "echo": false,
        "focus": false,
        "panel": "dedicated"
      },
      "problemMatcher": {
        "base": "$tsc-watch",
        "applyTo": "allDocuments"
      }
    }
  ]
}

[vdh]

@samesfahani-tuplehealth Please edit your comment to either say how this task relates directly to enableProjectDiagnostics, or else reword that it is a suggestion as a temporary workaround, not a fix. The distinction between workarounds and real actual fixes is an important one to make when commenting on issue threads.

[samesfahani-tuplehealth]

@vdh Fair enough, edited. Though I don't think this Issue in particular was around enableProjectDiagnostics either; the issue at hand was that we cannot view problems across the entire project even for files not currently in view.

[hi2u]

Regarding the issue with the unwanted node_modules errors, I've created a new issue to specifically discuss that: https://github.com/microsoft/vscode/issues/103539

@vhd / @martaver / @blackfan23 / @SupremeTechnopriest / @patroza / @jgoux / anyone else... If you could please add any more additional clues you might to that issue, it might help in getting this solved hopefully.

[PinkaminaDianePie]

The same issue as @jgoux, it doesn't work with "source.fixAll.eslint": true - eslint starts to check every file in the project, not only open files, and it rechecks entire project on every single change. VSCode just hangs. No idea why does it modify default ESLint behavior, but that's really a blocker

[SrBrahma]

"typescript.tsserver.experimental.enableProjectDiagnostics" really should be fixed and improved. It would make typescript way more powerful than already is.

[phatmann]

The solution posted by @samesfahani-tuplehealth works super well. This is crucial for me when I move an imported type from one file to another and need to find everywhere the imports broke. I am not seeing high CPU use, but if so you could just run it when you need it.

[vdh]

@phatmann That's a workaround, not a solution. Bypassing the feature and using another entirely different feature instead is not a way to fix the performance issues. I hate to be persistent about this but I would rather not have a bunch of noise drawing attention away from fixing this great (but experimental) feature. It could become something incredibly useful if it got the attention it deserves.

[phatmann]

@Vdh you are right of course. (And in fact a simpler version of the task, the built in tsk:watch task, works equally well for the workaround). My confusion is this: the workaround is so effective and efficient that I feel no need for the actual feature referenced in this issue. Am I missing something?

[vdh]

@phatmann If I wanted to run a Typescript watch task, I could already do that. This isn't just about running TS checks. It runs all of VSCode's checks on every project file. Typescript, ESLint, CSpell, etc… It's really powerful and useful to know that even if I forgot to open a file, I can find errors across the whole project (without running each linter manually across all files, maybe even having to resort to doing it externally in the terminal).

The only major flaw right now is that it goes overboard with running over literally every file, including normally-forbidden folders like node_modules.

[ruimarques]

That moment when you search how to do something with vscode but what you get is a 4yo open issue... 😢