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.

[dbaeumer]

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

[waderyan]

For reference here is a link to the issue - microsoft/TypeScript#11229

[plievone]

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.

[maxime1992]

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

[waderyan]

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

[johnfn]

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.

[WilliamChelman]

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

[adius]

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

[pzuraq]

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.

[peabnuts123]

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?

[pzuraq]

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.

[peabnuts123]

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

[cloudkite]

anyone experiencing this issue #34412?
if the exact same error occurs between subsequent builds it ignores it

[cr0cK]

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.

[apperside]

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

[chandanch]

👍

[ArtemFrontendACTUM]

Just use WebStorm

[lipe-dev]

Just use WebStorm

I would, really, if it stopped breaking everything else in my setup.

[ayush-seth]

Adding this to settings.json worked for me:

"typescript.tsserver.experimental.enableProjectDiagnostics": true,

[douglasg14b]

This works, but it just shows errors for everything under node_modules which is.... very much unwanted.

My tsconfig has:

  "include": ["src"],
  "exclude": ["node_modules"]

Which I would have assumed means it would exclude node_modules...?

Even if filtering via !**/node_modules** this still causes it to indefinitely hog resources, and the list of problems seems to forever grow and shrink without end. It also seems to kill pre-save tasks like lint-fix, causing files to not actually save...

[rafsaf]

Adding this to settings.json worked for me:

"typescript.tsserver.experimental.enableProjectDiagnostics": true,

For anybody still looking here, I can confirm this solution works like a harm.

It's also mentioned here: https://stackoverflow.com/questions/55201424/how-to-get-vscode-to-show-typescript-errors-for-files-not-open-in-the-editor#60116499

[nathanpovo]

One problem with the typescript.tsserver.experimental.enableProjectDiagnostics setting is that, whenever you re-install you npm packages using npm ci, you suddenly get a bunch of errors.

To fix that issue I always have to turn off the setting and turn it back on (change it from true to false and back to true) for the "JS/TS language features" to be re-initiliased.

[marinaglancy]

If anybody finds it useful, I created a VSCode extension "Bulk Problem Diagnostics"
https://marketplace.visualstudio.com/items?itemName=MarinaGlancy.bulk-problem-diagnostics

It allows to open all files in a folder and all subfolders in order to review problems. Splits large number of files in batches to prevent unloading.

It has a wide range of settings controlling how many files to open, what file types, what to exclude, how long to wait before opening files.

[ad-on-is]

tsconfig.json

{
    "compilerOptions": {
        "skipLibCheck": true,
    }
}

to disable errors/problems within node_modules

[Dejee98]

Whenever I rebuild solution, VS shows me all Errors and Warnings, but I understand that this is probably impractical for very large projects. I'm also a beginner so, sorry if what I said is not the proper way to do things.

[adamerose]

Anyone have advice for getting enableProjectDiagnostics working? I have it in my settings and still only see errors on files if they're open.

• Started a fresh project with npm create vite@latest typescript-sandbox -- --template react-ts
• Added a component with an error
• Disabled all extensions
• Commented out all settings aside from "typescript.tsserver.experimental.enableProjectDiagnostics": true

[ChristopherHaws]

You will always need to open one file to boot up the language service. From my experience, that setting will show you all errors for the ts projects which currently have open files, not all ts projects in the workspace.

[ADTC]

@marinaglancy thank you! You're an angel! I like how it opens in a hidden way. I was afraid it's going to open and close a bunch of tabs quickly (visually on my screen), but it just opens the files internally and checks them, then only opens a tab for them if a problem was found. Awesome!

Now, is there a way to automate it, so that it runs either periodically or runs when saving? But maybe that's not a good idea because it takes a while to check all files. My small project itself has 125 files already, imagine one with 3000 files. If only there was a way to go by references.

[Ploppy3]

I like that this is actively open and discussed after years.... LMAO Js and it's ecosystem are some nasty dumpster fire

Because it's not about fixing the existing issue of this experimental feature for TS or JS, it is about implementing a proper solution in the language server API for any language.

Note: Thank you for the constructive answer. Many people are subscribed to this issue.

[marinaglancy]

It would be a huge performance hit if all enabled extensions constantly analyse ALL files in the workspace for problems. Currently they usually only do it only when a file is open by listening to the "file open" and also "file edited" events

Maybe VSCode could introduce a new event "file waiting to be analysed" and advise all extensions to listen to it (and trigger it as configured)? But it would require changes to absolutely all extensions in the marketplace that report diagnostics.

@ADTC your question is specific to the "Bulk problem diagnostics" extension. Let's not pollute the discussion here, I created an issue in my own repo where we can discuss it

[M7ilan]

I found a temporary fix. Enable typescript.tsserver.experimental.enableProjectDiagnostics in VSCode settings. But, you need to be in a TS or JS file and restart the TS Server using >TypeScript: Restart TS Server from the command palette.

[jonlepage]

I found a temporary fix. Enable typescript.tsserver.experimental.enableProjectDiagnostics in VSCode settings. But, you need to be in a TS or JS file and restart the TS Server using >TypeScript: Restart TS Server from the command palette.

#13953 (comment)

[M7ilan]

I found a temporary fix. Enable typescript.tsserver.experimental.enableProjectDiagnostics in VSCode settings. But, you need to be in a TS or JS file and restart the TS Server using >TypeScript: Restart TS Server from the command palette.

#13953 (comment)

I still don't have it. Also, my friend did the same thing I did, and it's working fine for him.

[jthoward64]

This works, but it just shows errors for everything under node_modules which is.... very much unwanted.

My tsconfig has:

  "include": ["src"],
  "exclude": ["node_modules"]

Which I would have assumed means it would exclude node_modules...?

Even if filtering via !**/node_modules** this still causes it to indefinitely hog resources, and the list of problems seems to forever grow and shrink without end. It also seems to kill pre-save tasks like lint-fix, causing files to not actually save...

Anyone know a solution for this? skipLibCheck doesn't work in my case because a dumb library I am using ships ts files with their package for react-native (which I'm using) and causes tsc to check those files which immediately gives me a hundred errors. (yeah there are other issues with the library, we're trying to migrate away from it)

[interpolation-0]

I have the opposite issue with typescript.tsserver.experimental.enableProjectDiagnostics.

Files are incorrectly detected to have errors pertaining to an unresolved module, which is actually in the paths option of my tsconfig.json.

The errors only go away while the file with the error is currently active in the editor, not just opened.

There are 187 of these files and over 600 problems, so I'd like to keep them closed :)

[cyanff]

I have the opposite issue with typescript.tsserver.experimental.enableProjectDiagnostics.

Files are incorrectly detected to have errors pertaining to an unresolved module, which is actually in the paths option of my tsconfig.json.

The errors only go away while the file with the error is currently active in the editor, not just opened.

There are 187 of these files and over 600 problems, so I'd like to keep them closed :)

seconding this issue, anybody stumbled upon a solution?

[j1mmie]

I have the opposite issue with typescript.tsserver.experimental.enableProjectDiagnostics.
Files are incorrectly detected to have errors pertaining to an unresolved module, which is actually in the paths option of my tsconfig.json.
The errors only go away while the file with the error is currently active in the editor, not just opened.
There are 187 of these files and over 600 problems, so I'd like to keep them closed :)

seconding this issue, anybody stumbled upon a solution?

Also seeing this. Took me a while but I've finally determined the issue is related to enableProjectDiagnostics. It doesn't happen when enableProjectDiagnostics is false.

It's possible this is happening because enableProjectDiagnostics requires many files to be open, and the system's ulimit is too low? On my system (macos) it's 256. One solution is to use FSEvents so that fewer files need to be open for watching. To do that, add the following to your tsconfig at the root (sibling to compilerOptions)

  "watchOptions": {
    "watchFile": "useFsEventsOnParentDirectory",
    "watchDirectory": "useFsEvents",
    "fallbackPolling": "dynamicPriority"
  },

More info here: https://www.typescriptlang.org/docs/handbook/configuring-watch.html