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 - https://github.com/Microsoft/TypeScript/issues/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 :smile:

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

👍

[eladcandroid]

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

[enko]

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.

[ekulabuhov]

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

[ekulabuhov]

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

[chandanch]

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

[pabloli]

How can i disable this?

[DblK]

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

[jbrodriguez]

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 ?

[molinx]

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.

[sillero]

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

[daarong]

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.

[Darkle]

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

[pahofmann]

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.

[dakt]

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

[Domvel]

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

[simeyla]

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.

[ajayRaghav37]

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.

[KirilOkun]

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.

[mateuscb]

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.

[neoncom]

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.

[JonNeat]

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

[JonNeat]

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)

[uglycoyote]

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.

[yyynnn]

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

[matthewvolk]

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

[ajayRaghav37]

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.

[atkeranov]

Much needed feature for larger projects indeed. Any updates?

[IstoraMandiri]

@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

[dipacs]

+1

[zen0wu]

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.

[hasansaghir]

+1

[FishOrBear]

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?

[TomasHubelbauer]

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.

[martinog2]

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.