Skip to content
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 JavaScript and TypeScript files, not just opened ones #13953

Open
kevinjreece opened this issue Oct 18, 2016 · 190 comments
Assignees
Labels
feature-request Request for new features or functionality typescript Typescript support issues
Milestone

Comments

@kevinjreece
Copy link

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
Copy link
Member

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

@waderyan
Copy link

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

@plievone
Copy link

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.

@waderyan waderyan added the typescript Typescript support issues label Jan 3, 2017
@mjbvz mjbvz self-assigned this Jan 26, 2017
@maxime1992
Copy link

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

@waderyan
Copy link

@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
Copy link
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
Copy link

@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
Copy link

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
Copy link

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
Copy link

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
Copy link

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
Copy link

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
Copy link

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

@cr0cK
Copy link

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
Copy link

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
Copy link

👍

@ArtemFrontendACTUM
Copy link

Just use WebStorm

@lipe-dev
Copy link

Just use WebStorm

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

@ayush-seth
Copy link

ayush-seth commented Aug 16, 2022

Adding this to settings.json worked for me:

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

@douglasg14b
Copy link

douglasg14b commented Aug 19, 2022

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
Copy link

rafsaf commented Dec 29, 2022

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
Copy link

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
Copy link

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
Copy link

tsconfig.json

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

to disable errors/problems within node_modules

@Dejee98
Copy link

Dejee98 commented Aug 2, 2023

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
Copy link

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
Copy link

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
Copy link

ADTC commented Oct 26, 2023

@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
Copy link

Ploppy3 commented Oct 26, 2023

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
Copy link

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
Copy link

M7ilan commented Nov 22, 2023

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
Copy link

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
Copy link

M7ilan commented Nov 22, 2023

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
Copy link

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
Copy link

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
Copy link

cyanff commented Mar 31, 2024

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?

@mbomb007

This comment has been minimized.

@j1mmie
Copy link

j1mmie commented Jul 30, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-request Request for new features or functionality typescript Typescript support issues
Projects
None yet
Development

No branches or pull requests