New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: Show all errors and warnings in project for all files, not just opened ones #13953

Open
kevinjreece opened this Issue Oct 18, 2016 · 39 comments

Comments

Projects
None yet
@kevinjreece

kevinjreece commented Oct 18, 2016

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

This comment has been minimized.

Member

dbaeumer commented Oct 25, 2016

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

@waderyan

This comment has been minimized.

Contributor

waderyan commented Oct 25, 2016

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

@plievone

This comment has been minimized.

plievone commented Dec 22, 2016

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

This comment has been minimized.

maxime1992 commented Jan 26, 2017

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

@waderyan

This comment has been minimized.

Contributor

waderyan commented Jan 26, 2017

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

@mjbvz mjbvz modified the milestone: Backlog Feb 23, 2017

@johnfn

This comment has been minimized.

Contributor

johnfn commented Mar 12, 2017

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

This comment has been minimized.

WilliamChelman commented Apr 7, 2017

@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

This comment has been minimized.

adius commented Jul 11, 2017

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

@waderyan waderyan removed their assignment Jul 13, 2017

@pzuraq

This comment has been minimized.

pzuraq commented Aug 9, 2017

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

This comment has been minimized.

peabnuts123 commented Aug 11, 2017

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

This comment has been minimized.

pzuraq commented Aug 11, 2017

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

This comment has been minimized.

peabnuts123 commented Aug 11, 2017

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

This comment has been minimized.

cloudkite commented Sep 14, 2017

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

@cr0cK

This comment has been minimized.

cr0cK commented Oct 29, 2017

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

This comment has been minimized.

apperside commented Nov 16, 2017

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

This comment has been minimized.

chandanch commented Nov 24, 2017

👍

@eladcandroid

This comment has been minimized.

eladcandroid commented Dec 17, 2017

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

@enko

This comment has been minimized.

enko commented Feb 8, 2018

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

This comment has been minimized.

ekulabuhov commented Feb 14, 2018

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

This comment has been minimized.

ekulabuhov commented Feb 14, 2018

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

@chandanch

This comment has been minimized.

chandanch commented Feb 15, 2018

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

capture

@pabloli

This comment has been minimized.

pabloli commented Feb 15, 2018

How can i disable this?

@DblK

This comment has been minimized.

DblK commented Feb 15, 2018

@jbrodriguez

This comment has been minimized.

jbrodriguez commented Feb 16, 2018

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

This comment has been minimized.

molinx commented Feb 16, 2018

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

This comment has been minimized.

sillero commented Apr 10, 2018

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

@daarong

This comment has been minimized.

daarong commented Apr 30, 2018

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

This comment has been minimized.

Darkle commented Apr 30, 2018

@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

This comment has been minimized.

pahofmann commented Jul 18, 2018

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

This comment has been minimized.

dakt commented Aug 4, 2018

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

This comment has been minimized.

Domvel commented Aug 14, 2018

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

This comment has been minimized.

simeyla commented Aug 16, 2018

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

This comment has been minimized.

ajayRaghav37 commented Sep 22, 2018

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.

@bearoutthere

This comment has been minimized.

bearoutthere commented Sep 25, 2018

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

This comment has been minimized.

mateuscb commented Sep 25, 2018

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

This comment has been minimized.

neoncom commented Oct 21, 2018

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

This comment has been minimized.

JonNeat commented Nov 10, 2018

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

@JonNeat

This comment has been minimized.

JonNeat commented Nov 10, 2018

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

This comment has been minimized.

uglycoyote commented Dec 18, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment