"Problems" panel is displaying TypeScript errors from /node_modules/ packages with typescript.tsserver.experimental.enableProjectDiagnostics enabled

[hi2u]

Summary

I'm using vscode insiders edition, and with the config option "typescript.tsserver.experimental.enableProjectDiagnostics": true to display TypeScript errors for my whole projects in the "Problems" panel along the bottom of the screen, i.e. the feature introduced in #13953

I seem to have an inconsistent issue with the "Problems" panel randomly displaying errors from /node_modules/ code (which I obviously can't control/fix):

I can see that the error in the screenshot above refers to one of my project files (App.test.tsx) - but the error itself seems to be coming from the package /node_modules/ts-invariant (see example tsconfig.json files further down). I've tried lots of fiddling with my tsconfig.json - but the thing is that other stuff that shows TypeScript errors never shows these node_modules errors, so as far as I'm aware, vscode should be the same?...

• ✔️ When I run tsc from the command line, I don't see these errors at all.
• ✔️ My project is setup with create-react-app + typescript, which typically yells at me and refuses to even render when there's any TypeScript errors - but it never mentions theses node_modules related errors at all.
• ❌ The only place I ever see these errors is in the vscode "Problems" panel.

And many other people have reported the exact same issue in the comments in: #13953 - so seems it's not just me / my project specifically.

Random coming/going

• But it's seemingly random, I haven't been able to figure out a consistent way to reproduce it immediately.
• Usually when I first start vscode, it won't show them for a while, but they typically pop up about 15+ minutes later
  • ...note that before these node_modules errors show, my own project-wide TypeScript errors are already working, so it's not coming/going at the end same time that the rest of the project-wide TS errors are showing - it seems to have its own timing that is affected by something else
• Sometimes they just go away on their own for a while, without me doing anything
• Sometimes restarting the typescript service makes them go away for a while
• Restarting vscode entirely usually makes them it go away for a while too
• During these "comings and goings": I'm not making any changes to tsconfig.json or any vscode settings at all

Steps to Reproduce:

1. My project was originally created using: npx create-react-app my_project_name --template typescript - but from memory, I think I've seen these issues with other non-react projects too.
2. It seems to be a regular this when using package: https://www.npmjs.com/package/ts-invariant - but again, I think I've also seen the issue with other packages in other projects too - but being hard to reproduce, I can't find them right now
3. Beyond that - I'm not sure how to easily reproduce it immediately, due to the seeming randomness of it coming/going

VSCode Version:

Version: 1.48.0-insider (user setup)
Commit: 15e798e081984a17eae00de91adf4479190d5ed2
Date: 2020-07-28T10:39:18.007Z
Electron: 9.1.0
Chrome: 83.0.4103.122
Node.js: 12.14.1
V8: 8.3.110.13-electron.0
OS: Windows_NT x64 10.0.18363

Example tsconfig.json file from one of my projects

{
    "compilerOptions": {
        "target": "es5",
        "lib": ["dom", "dom.iterable", "esnext"],
        "allowJs": true,
        "skipLibCheck": true,
        "esModuleInterop": true,
        "allowSyntheticDefaultImports": true,
        "strict": true,
        "forceConsistentCasingInFileNames": true,
        "module": "esnext",
        "moduleResolution": "node",
        "resolveJsonModule": true,
        "isolatedModules": true,
        "noEmit": true,
        "jsx": "react",
        //"rootDir": "./src" // <--- I've tried both with and without this, no difference
    },
    "include": ["src"],
    "exclude": ["node_modules", "./node_modules/*"]
}

Example tsconfig.json from /node_modules/ts-invariant/tsconfig.json

{
  "extends": "../../tsconfig.json",
  "compilerOptions": {
    "rootDir": "./src",
    "outDir": "./lib"
  }
}

Does this issue occur when all extensions are disabled?: Yes

• Yes, I've tried running with: "C:\Users\username\AppData\Local\Programs\Microsoft VS Code Insiders\Code - Insiders.exe" --disable-extensions
• ...and it's the same thing, problem doesn't occur immediately, comes and goes in the same way as when running vscode normally.

[nad182]

I'm also noticing the number in problems tab constantly changing, regardless if I run a script to start the project or not, or perform any other actions. I just open VS Code (v1.47.1) and notice number get to 100+, then 300+, then 400+, then drop to 200+, go back up, etc... Here's the screenshot from the top of the list, just so you can have an idea:

My system info:

Version: 1.47.1
Commit: 485c41f
Date: 2020-07-13T22:43:02.577Z
Electron: 7.3.2
Chrome: 78.0.3904.130
Node.js: 12.8.1
V8: 7.8.279.23-electron.0
OS: Darwin x64 19.3.0

[hi2u]

Yes actually that's something I forgot to mention in the OP. The number of errors jumps around a bit.

For the "6" node_modules/ts-invariant errors shown in my screenshot at the very top of this page... just in the last couple of days I've noticed that number jump around from about 4 - 11.

And haven't even touched my src/App.test.tsx file that it mentions for over a month.

[PinkaminaDianePie]

I have exactly the same issue with ts-invariant when enableProjectDiagnostics is enabled. node_modules excluded as well

[KapitanOczywisty]

I had this enabled for some reason and when I've added @tensorflow/tfjs-node, cpu (and pagefile) had a very bad time. Finally I realized what caused this issue and disabled enableProjectDiagnostics.

[mrousavy]

I'm also having those errors. I was really shocked when I first tried out this experimental feature and noticed 3k+ errors in my project 😅

Is there any option to let it exclude node_modules? Feels like my MacBook is trying to kill itself by scanning the entire project including node_modules....

[jerrygreen]

I confirm the bug is there! I really like the concept behind the feature to show all my project's errors in disregard if the files are open, but this feature is currently poorly supported so that becomes unusable. I would never want it to analyze node_modules :\

That doesn't seem to happen with all entirety of projects though, but it's hard to tell why exactly it's happening and why it's so random and continue to disappear and appear again sometimes. My screenshot:

Btw, it doesn't seem project's tsconfig.json is being used here, because I certainly have esModuleInterop flag enabled in my root tsconfig.json, so it seems it's using some another tsconfig.json for the library there.

More than that: one single file sometimes appears valid and no errors (with valid types, etc.), fully working, but then with no change it suddenly has errors, then again it's good, etc. - the same random behavior. So it seems like different tsconfig.json are applied to the same files, - sometimes it's one config, sometimes it's a another. And that seems to be source of the problem. VSCode can't handle more than one tsconfig inside the project tree. If there happens to be another tscofig somewhere in subfolders, - the behavior becomes weird, and random, and also look into node_modules. Here's the problematic tsconfig:

{
  "extends": "assemblyscript/std/assembly.json",
  "exclude": ["node_modules", "./**/*.test.ts"]
}

This config above extends assembly.json extends tsconfig-base.json

If I delete it, VSCode stops inspecting node_modules, and this another behavior with random errors inside my file also disappears. But in return I get my types simply broken in a subfolder :\

[mjbvz]

As noted, this is caused by typescript.tsserver.experimental.enableProjectDiagnostics . Please disable this experimental setting if you are running into issues with it

[PinkaminaDianePie]

@mjbvz nice way to fix the issue! Would you suggest stopping using VSCode in case anybody found any other bugs in it?

[jerrygreen]

Oh, I’m actually glad it got into Backlog. Thanks @mjbvz! Can’t wait it being fixed

[whazor]

Until then to avoid those problems I use !**/node_modules** in the search filter.

[jerrygreen]

@whazor but this doesn't hide those errors in "problems" panel, isn't it?

[whazor]

Adding the ! before the node_modules, makes sure you do not see any irrelevant problems.

[jerrygreen]

@whazor, oh I actually didn’t even notice “problems” tabs has such a filter. I was confused first, but now I understand about what filter you’re talking about. Yes, this helps a lot, thanks

[jerrygreen]

Earlier I thought I'm getting this bug only in projects where multiple tsconfig.json are present, but today I noticed I'm getting this bug even in a project with a single tsconfig.json. Still, it's hard to describe concrete steps to reproduce the bug: it happens randomly time to time. As much randomly those problems disappear after a while. Weird

[frank-weindel]

I'm noticing this bug with node_modules folders of folders that I don't even have loaded in my workspace anymore. I even restarted VS Code to confirm. Not sure where this feature is getting it's list of folders to scan, but it's somehow picking up perhaps stale cached copies of it.

Edit: Never mind, it seems like I had one file from the folder I no longer had in my workspace open in a tab. It seems like this feature, as might already be known by some, is based on what files you have open and not necessarily what folders you have added in your workspace.

[olafur-palsson]

What about having tsservice just filter out .gitignored files? The performance of enableProjectDiagonstics will still be bad but the node_module errors can be removed.

[Ploppy3]

@whazor are you talking about the files.exclude setting? Because I tested it and I'm still getting errors.

[jerrygreen]

@Ploppy3 He's talking about this filter here. Not ideal solution, but hides the irrelevant information (doesn't change the counter though):

[vdh]

Hiding the problems doesn't negate the large CPU hit caused by the unwanted processing of hundreds of (normally excluded) files.

[lucasbasquerotto]

Also, hiding the problems still shows the total number of problems (I try to always let my projects without problems, and when a problem shows, I want to fix it ASAP).

[jerrygreen]

I 100% agree with you both. It is still heck of a problem

[Ploppy3]

@mjbvz What is the state of this issue ?

[mjbvz]

Closing in favor of microsoft/TypeScript#36664

This feature is currently implemented in rather suboptimal way (which is why the setting is marked experimental). If you're running into trouble using it, try setting up a watch task instead, which should perform better overall, the obvious downside being that you have to setup the watch task in the first place

[vdh]

@mjbvz But it isn't flawed due to being suboptimal, it's flawed because it was misconfigured and doesn't exclude node_modules like it should, and so tries to churn through way too many third-party files.

What about the non-Typescript applications for this feature? Whether it was intended or not, it also runs other checks over these files. It's useful to have a generic way to run checks from all extensions. For example, am I going to have to reverse-engineer the Code Spell Checker extension into a task just to be able to do the equivalent with a watch task…?