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

@waderyan this is a feature request for the builder work we discussed with the TS team.

For reference here is a link to the issue - https://github.com/Microsoft/TypeScript/issues/11229

Well, I just use a watching build task with "problemMatcher": "$tsc-watch" (see https://code.visualstudio.com/Docs/editor/tasks#_processing-task-output-with-problem-matchers) and all errors and warnings are properly shown in the Problems view. It is quite a nice workflow because changes in open files are noticed immediately due to language server, but save triggers incremental compilation (with tsc --watch) which still takes a while, but I can control that latency by saving/not saving yet.

any ETA on this ? There's a lot of issues opened for that feature and not sure if I missed anything or not :smile:

@maxime1992 thanks for the follow up. This is on our radar. No firm timeline yet.

Something I didn't realize was that it's possible to do this with the Tasks infrastructure that VSCode has. All you have to do is put this into your tasks.json:

{
  "version": "0.1.0",
  "command": "tsc",
  "isShellCommand": true,
  "args": ["-w", "-p", "."],
  "showOutput": "silent",
  "isBackground": true,
  "problemMatcher": "$tsc-watch"
}

Then just run it and you'll get all of the errors across your entire project in the problems view.

I'm a bit perplexed why this isn't displayed more prominently. It's super useful and cool.

@johnfn Great solution, thanks a lot. I would even add the "--noEmit" argument if the sole purpose of the task is to show the errors

{
  "version": "0.1.0",
  "command": "tsc",
  "isShellCommand": true,
  "args": ["-w", "-p", ".", "--noEmit"],
  "showOutput": "silent",
  "isBackground": true,
  "problemMatcher": "$tsc-watch"
}

@kevinjreece You can use the Semantic History feature of iTerm (https://www.iterm2.com/documentation-one-page.html) to prevent the "fun dance between my terminal and VS Code". When cmd clicking on the filename + line number it automatically opens the corresponding line in vscode!

Anyone know if it's possible to open files with errors/in the Problems panel with a keyboard shortcut? Real pain to keep switching between mouse and keyboard, even after running the task.

You can open the Problems panel with Ctrl+Shift+M (or Cmd+Shift+M), it's under Keyboard Shortcuts as "Show Problems" - is that what you mean?

No, I'd like a shortcut to go to the next file that has an error, whether or not it's open.

I was looking into making an extension to do it, but the API is locked down tight, commands don't have access to the MarkerService (tracks problems) in any way that I can see.

Oh I see. That could be quite useful. Sounds like the Problems area of vscode in-general has a lot of opportunity to improve.

anyone experiencing this issue https://github.com/Microsoft/vscode/issues/34412?
if the exact same error occurs between subsequent builds it ignores it

The trick with tsc into a debug task is not always possible, for example in a Vue project with custom Webpack loaders to handle .vue files (tsc can't parse Vue files out of the box).

But you can find a way to have all errors by watching and compiling your project into a VS Code terminal.

For example, I did this npm script:
"live-check": "webpack --config ./build/webpack.dev.conf.js -w --display none",

And I launch it via "npm run live-check" into a VS terminal and I have all errors in real time.

even with the solution from @johnfn , I can only see errors from open files :(.
I see the task running in the output tab, but does not show any error

tasks.json:

{
    "version": "0.1.0",
    "command": "tsc",
    "isShellCommand": true,
    "args": ["-w", "-p", ".", "--noEmit"],
    "showOutput": "silent",
    "isBackground": true,
    "problemMatcher": "$tsc-watch"
  }

tsconfig.json

{
  "compilerOptions": {
    /* Basic Options */
    "target": "es2015",                       /* Specify ECMAScript target version: 'ES3' (default), 'ES5', 'ES2015', 'ES2016', 'ES2017', or 'ESNEXT'. */
    "module": "es2015",                       /* Specify module code generation: 'commonjs', 'amd', 'system', 'umd' or 'es2015'. */
    // "lib": [],                             /* Specify library files to be included in the compilation:  */
    "allowJs": true,                          /* Allow javascript files to be compiled. */
    // "checkJs": true,                       /* Report errors in .js files. */
    "jsx": "react-native",                    /* Specify JSX code generation: 'preserve', 'react-native', or 'react'. */
    // "declaration": true,                   /* Generates corresponding '.d.ts' file. */
    "sourceMap": true,                        /* Generates corresponding '.map' file. */
    // "outFile": "./",                       /* Concatenate and emit output to single file. */
    "outDir": "./build",                      /* Redirect output structure to the directory. */
    "rootDir": "./src",                       /* Specify the root directory of input files. Use to control the output directory structure with --outDir. */
    "removeComments": false,                  /* Do not emit comments to output. */
    // "noEmit": true,                        /* Do not emit outputs. */
    // "importHelpers": true,                 /* Import emit helpers from 'tslib'. */
    // "downlevelIteration": true,            /* Provide full support for iterables in 'for-of', spread, and destructuring when targeting 'ES5' or 'ES3'. */
    // "isolatedModules": true,               /* Transpile each file as a separate module (similar to 'ts.transpileModule'). */

    /* Strict Type-Checking Options */
    "strict": true,                           /* Enable all strict type-checking options. */
    "noImplicitAny": true,                    /* Raise error on expressions and declarations with an implied 'any' type. */
    "strictNullChecks": true,                 /* Enable strict null checks. */
    "noImplicitThis": true,                   /* Raise error on 'this' expressions with an implied 'any' type. */
    "alwaysStrict": true,                     /* Parse in strict mode and emit "use strict" for each source file. */

    /* Additional Checks */
    // "noUnusedLocals": true,                /* Report errors on unused locals. */
    // "noUnusedParameters": true,            /* Report errors on unused parameters. */
    // "noImplicitReturns": true,             /* Report error when not all code paths in function return a value. */
    // "noFallthroughCasesInSwitch": true,    /* Report errors for fallthrough cases in switch statement. */

    /* Module Resolution Options */
    "moduleResolution": "node",               /* Specify module resolution strategy: 'node' (Node.js) or 'classic' (TypeScript pre-1.6). */
    // "baseUrl": "./",                       /* Base directory to resolve non-absolute module names. */
    // "paths": {},                           /* A series of entries which re-map imports to lookup locations relative to the 'baseUrl'. */
    // "rootDirs": [],                        /* List of root folders whose combined content represents the structure of the project at runtime. */
    // "typeRoots": [],                       /* List of folders to include type definitions from. */
    // "types": [],                           /* Type declaration files to be included in compilation. */
    "allowSyntheticDefaultImports": true      /* Allow default imports from modules with no default export. This does not affect code emit, just typechecking. */

    /* Source Map Options */
    // "sourceRoot": "./",                    /* Specify the location where debugger should locate TypeScript files instead of source locations. */
    // "mapRoot": "./",                       /* Specify the location where debugger should locate map files instead of generated locations. */
    // "inlineSourceMap": true,               /* Emit a single file with source maps instead of having a separate file. */
    // "inlineSources": true,                 /* Emit the source alongside the sourcemaps within a single file; requires '--inlineSourceMap' or '--sourceMap' to be set. */

    /* Experimental Options */
    // "experimentalDecorators": true,        /* Enables experimental support for ES7 decorators. */
    // "emitDecoratorMetadata": true,         /* Enables experimental support for emitting type metadata for decorators. */
  },
  "include": [
    "src/**/*",
    "./node_modules/react-native-dev-kit/**/*"
  ],
  "exclude": [
    "__tests__",
    "index.android.js",
    "index.ios.js",
    "build",
    "local_history",
    "node_modules"
  ]
}

Why can't I see errors from closed files (I am sure that there are errors) ?

👍

As @apperside said.. the task only show errors when the file has changed..

With the new feature that error are displayed in the workspace in the sidebar, for this working out of the box would be greatly appreciated.

Seems like the task format changed a bit in the latest versions of vscode. New format is:

        {
            "label": "Monitor TS Errors",
            "command": "./node_modules/.bin/tsc",
            "type": "shell",
            "args": ["--watch", "--project", "."],
            "presentation": {
                "echo": true,
                "reveal": "always",
                "focus": false,
                "panel": "shared"
            },
            "isBackground": true,
            "problemMatcher": "$tsc-watch"
        }

Do you start the task each time you open VSCode? Or is there a way to automatically launch it?

I guess the latest version of VS code shows the count of errors per file

How can i disable this?

// Show Errors & Warnings on files and folder.
"problems.decorations.enabled": true,

Simply put this to false ;)

On Thu, Feb 15, 2018 at 1:36 AM, pabloli notifications@github.com wrote:

How can i disable this?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/vscode/issues/13953#issuecomment-365838054,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAy0aayEHkVuxumJRuZz-mdWmBvBhdn9ks5tU9B2gaJpZM4KaH3J
.

This is what I'm using

{
  "label": "TSCompileAll",
  "type": "shell",
  "command": "./node_modules/.bin/tsc --watch --noEmit --project .",
  "problemMatcher": ["$tsc-watch"]
}

It's invaluable, I wonder if it could be made default or at least a setting.

Is it possible to autostart this task on a workspace or project ?

I use this:

{
    "version": "2.0.0",
    "tasks": [
        {
            "label": "tsc watch",
            "type": "shell",
            "command": "./node_modules/.bin/tsc",
            "isBackground": true,
            "args": ["--watch", "--noEmit", "--project", "www"],
            "group": {
                "kind": "build",
                "isDefault": true
            },
            "presentation": {
                "reveal": "never",
                "echo": false,
                "focus": false,
                "panel": "dedicated"
            },
            "problemMatcher": "$tsc-watch"
        }
    ]
}

I use this extension to run the task on startup: https://marketplace.visualstudio.com/items?itemName=yukidoi.blade-runner

I still don't know how to keep the errors of a file (in the Problems panel) when closing it.

Having an option to keep the problems listed in the panel after you close a file would be very helpful.

Does somebody have a workaround for this issue? For medium to large projects it can be quite cumbersome to open every file to ensure no errors are present.

Is there a way to open all files at once with one command? That would be an acceptable workaround to me.

@daarong I usually have eslint-watch running in the terminal while I'm coding in vscode to check the whole project. It's not quite as good as having all the linting info in vscode, but it's a decent fallback for seeing at a glance whether any files in your project have errors in them.

Does anyone have a workaround for this for java files?
I want to see all errors of all files in the problems panel at any time, not only the errors of open files.

Is this a joke? I have about 2,000 files should I go and open all of them manually to search for lint errors???

Is there a way to trigger ts lint in vs code? I could use e. tslint to display it in the console.
It would be great if I could trigger VS Code to scan all files in src folder for errors (syntax and linter)
In other words: How to open all files (ts) in src folder at the same time?

Don't search in other folders like node_modules. ... Just for the protocol. 😄
Maybe a include / exclude path option would be nice? ...

About a month ago I had the little red icons next to my files in the workspace viewer. Now they're gone and I have no idea how I did it. Either a new version of VSCode changed the way it works or I installed an extension that broke it. How to get it working again? I've never even heard of tasks.json and the fact that it worked before suggests to me it is now the default behavior.

Here is how you can see all problems in less than 10 seconds.

You use a little trick.

Open replace all in files (Ctrl + Shift + H).

Replace ; with ;

Hit replace all. That's it. Now, check Problems.

The assumption here is that all files have at least one semicolon. For bigger projects, if you get a warning asking you to refine your search, just enter something that is common in all files but is not present a lot.

Any update on this? Although Ajay's shortcut work it feels rather hacky. Seem like this is an obvious and easy win for VSC. A switch "Show all errors / Show errors for open files" would be all that's required.

Another thought, instead of having this automatically happen on file change. I would be totally OK with having a button in the bottom bar or a command that I can explicitly run that would check all files.

It is correct, I think that the issue has to do with coordinating TS service that checks all opened files and on the other hand checking the files that are closed and are not normally checked automatically, is that correct? So the easy solution is to ensure that problems pane recieves all TS problems from a single source, is that correct?

Seeing how the problem is not solved by the vscode team (?), a proposal:

Should it not be possible to solve this via an addon or via vscode task problem matcher? Because then you could ensure what and when the problems pane shows anyway all by yourself? Then you would just have to somehow disable vscode from showing its stuff? Can a vscode dev tell me if something like this would be workable?

However I still think this basic stuff should be handled by vscode itsself. It's not like TS errors solve themselves when you close files... Just make TS server handle all files, open or not, should do the tricks. Should be an option of course, but an option it should be.

How can this not be the most critical of all issues to solve first? The IDE is broken until fixed.

Okay so this is a hacky solution.
Use @plievone's solution by making a task use $tsc-watch. Then get a plugin like AutoLaunch to run the task every time the Visual Studio Code is opened. (https://marketplace.visualstudio.com/items?itemName=philfontaine.autolaunch)

to expand on @mateuscb's suggestion, maybe something in the context menu of the file explorer would be good where you could right click on a particular folder and do "find problems in folder" would be a good option, as it would allow the user to decide the trade off between scope versus speed.

Dont do @ajayRaghav37 suggestion, it will hang vscode.
Damn, i will not gonna write ts code ever again in future)

Any updates or ideas of when this will be put into the pipeline? Would be great to have this feature out of the box.

ES-Lint has introduced a new task in VS Code. You have to enable it in the workspace setings.

"eslint.provideLintTask": true

Just go to terminal menu and select run task, then choose

eslint: lint whole folder.

You can also auto-fix most problems by running the following command in the terminal:

.\node_modules\.bin\eslint.cmd --fix .

Reference: https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint

While we still await the problem scanner in VS Code, this is a good enough alternative if you use eslint.

Much needed feature for larger projects indeed. Any updates?

@ajayRaghav37, it looks like eslint isn't able to catch typing errors, just linting rules:

https://github.com/typescript-eslint/typescript-eslint/issues/36#issuecomment-478820127

+1

Up this. I also think that it should be possible to disable the builtin TS checking and linting and just use the results from the build task.

+1

I now run tsc --noEmit -w to solve this problem.

But I think it would be better to share a ts-server with VSCode.

But why hasn't it been implemented for so long?

Is anyone here familiar with the TS language server? Does the LSP API lack a way to communicate this to the IDE? Is this a performance concern? Clearly people are passionate about the lack of this feature (I am), so I think there would be interest in community help on getting this past the finish line.

But that is if the problem here is just the lack of manpower on the VS Code team.

If the issue is different (larger impact on the VS Code architecture, a change to LSP required, unclear performance impact, UX considerations), knowing this would help explain why this seemingly straightforward feature takes so much time.

I see various comments in this issue about how the responsibility of this is on the TypeScript team and not the Visual Studio Code team. But this is also a problem with VS Code's built in '@ts-check' functionality. The workarounds mentioned in this post to use a task executing the 'tsc' command don't work for me because I don't have tsc installed (I'm only using @ts-check and jsdoc).

Before, I used to click every file in my project to find the errors. That was tedious, but at least the problems didn't disappear from the side bar once I closed the file. After one of the updates of the past few months, this problem was introduced: #73153.

How can this not be the most critical of all issues to solve first? The IDE is broken until fixed.

I agree.

When?

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

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.

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...

October 2019 and this is still at large.

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

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

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

Who cares. Yet, I am not even able to put the damn task up and running to check the ts files.

The provided guide seems like learning a whole new fucking programming language.
We do work and produce, I don't have time to waste learning all the webpack (and similar tools) bandwagon of bullshit to put up a script that checks my ts files on a IDE (I CALL IT IDE ok?) that doesn't even supports the language the same creators of the IDE created correctly....

what a bullshit

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.

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

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.

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.

Three years later... Any news?

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 :-(

3 years and still open :dancer:

3 years and still open

Yay, random downvotes from idiots.

Anyway, this is an annoying issue come on!!! You realize one has hundreds of files in a serious business project right?
How we are supposed to keep track of them, by mind?

It's one of the basic functions for which people use IDEs.....

And now it seems it's propagating also to visual studio and its intellisense from time to time

Btw the task things seems at least to mitigate it, and for ts files it seems that there are also available some control scripts. I don't know if they get installed by all the angular/typescript extensions from the extension manager in vscode, but if u search in the task search bar (which is shown [here])(https://code.visualstudio.com/docs/editor/tasks) you can search something like the watch or something like that that does the trick everytime you compile (seems it does it along with the normal compilation process, which is another task too)

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.

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?

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.

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 😞

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

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~

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.

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.

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?

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.

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.

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.

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

@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.

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

@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.

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

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.

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.

Excluding the node_modules would be a no1 fix :)

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;
                 }

1. npm install or yarn
2. Restart VSCode

= profit?

@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.

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… 😢

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.

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

@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.

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.

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"
      }
    }
  ]
}

@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.

@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.

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.

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

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

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.

@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.

@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?

@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.

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

How much money and where do I send?

For those having CPU issues or problems with this feature scanning node_modules, make sure you do NOT have a shared or "workspace" tsconfig.json somewhere like the root of your repository unless it includes:

"files": []

otherwise, the default is to include all TypeScript files located at or beneath the folder containing the tsconfig, which likely will cause it to analyze too many files.

This feature is working fine for me in a large monorepo using yarn workspaces and composite typescript "projects".

Great advice @dinofx. In addition, you can use include and exclude, instead of files, per the docs.

      "include": ["src/**/*"],
      "exclude": ["node_modules", "test/**/*"],

That's correct, but there's no need to exclude something that doesn't match the "include" globs.

"files": [] is more succinct for a "workspace" tsconfig.json file (one that just references a bunch of other tsconfig.json files). It's not well documented, but you need to name the config files for packages and the workspace tsconfig.json, or a lot of features won't work properly (this features, find references, refactoring, etc).

For a shared config that is extended, it's probably better to name it something like tsconfig.browser.json, tsconfig.node.json, etc. That naming prevents anything from ever caring about the "files" or "includes", so you can likely omit them.

@dinofx The file traversal issue isn't restricted to just Typescript. Additionally, not everyone uses a monorepo.