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

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 https://github.com/microsoft/vscode/issues/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):

typescript_problems_from_node_modules

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: https://github.com/microsoft/vscode/issues/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.

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Reactions: 27
  • Comments: 24 (3 by maintainers)

Most upvoted comments

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

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

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

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

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

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

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:

image

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

Closing in favor of https://github.com/microsoft/TypeScript/issues/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

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

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:

image

My system info:

Version: 1.47.1 Commit: 485c41f9460bdb830c4da12c102daff275415b53 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

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…

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