How to get VSCode to show TypeScript errors for files *not* open in the editor?

Question

In my create-react-app@2.1.8 TypeScript/React app, TS compiler errors are only shown in the Problems pane for files I have open in the VS Code editor. As a result I sometimes don't catch errors until I actually run the app.

How can I get TypeScript to automatically check for compiler errors in all code files as soon as I open the workspace, or when I save changes to a file?

I've tried adding "watch": "tsc --watch" as a script in package.json and then doing npm run-script watch in an integrated terminal pane, but this has two problems:

• errors show up in the terminal pane but don't populate the Problems pane in VSCode
• I have to manually run it, instead of it automatically starting when the workspace loads

Is there a better solution?

BTW, this is the same question as Show project wide TypeScript problems/errors in webstorm, but about Visual Studio Code instead of webstorm.

Answer 1

As of 24.10.2023 There is an experimental feature in generally available VS Code to enable project wide problem reporting. Add the following to your settings.json:

"typescript.tsserver.experimental.enableProjectDiagnostics": true

It is still an experimental feature (after few years of neglect), so it can be both overwhelming and underwhelming at the same time. Good thing is that it apparently works with other languages as well and respects your config files.

People report that this option scans the contents of node_modules even thought it is in exclude list, but adding 'skipLibCheck' helps

Watch this space.

Answer 2

A very similar answer than the other that was sent here but I bit different and worked great for me.

1. Add this line to your .vscode/settings.json file:

"eslint.lintTask.enable": true

1. Add this task or create the file if it not exists on .vscode/tasks.json with:

{
  "version": "2.0.0",
  "tasks": [
    {
      "type": "npm",
      "problemMatcher": ["$eslint-stylish"],
      "label": "eslint: lint whole folder",
      "script": "lint",
      "presentation": {
        "reveal": "never",
        "panel": "new"
      },
      "runOptions": { "runOn": "folderOpen" },
      "detail": "Run eslint for all files on the workspace folder",
      "options": {
        "configFile": ".eslintrc.js",
        "ignorePath": ".eslintignore"
      }
    }
  ]
}

PS.: problemMatcher is what makes the 'magic' on the problems tab.

Answer 3

If you get typescript errors from bad reference because of you dont have opened that references file/module too. You have to go to Options->TextEditor->Javascript/typescript -> Project -> and uncheck Ignore visual studio solution files.

Have a good day;

Answer 4

As of November 2019, unfortunately this isn't supported by VS Code out of the box. See https://github.com/Microsoft/vscode/issues/13953.

The best workaround that I could find is to add a task to tasks.json that will run tsc --watch, and configure it to run when the workspace or folder is opened.

Below is a sample config for tasks.json. Note that "www" in the snippet below refers to the folder with tsconfig.json that you want to check. Replace it with the name of your own folder, relative to the root of your workspace.

{
    "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",
            "runOptions": {
                "runOn": "folderOpen"
            }
        }
    ]
}

Note that auto-run tasks don't seem to be enabled by default. To opt into auto-run tasks, follow the instructions here: https://stackoverflow.com/a/58866185/126352

This solution was adapted from @molinx's answer in the GitHub issue linked above, and it was improved thanks to @kumar303's comment below.