Show all errors and warnings in project for all Typescript files, not just opened ones

[niebloomj]

We do see all errors and warnings in the "problems" tab when we open a Typescript file with errors, but they are removed from the problems tab when we close the file. It would be great to be able to see all the problems of all the files in a project.

This was requested to be globally implemented in the vscode issue at microsoft/vscode#13953 but we were told that this is not something to be implemented globally, but per language/plugin.

I do understand not everyone would like to have this feature, or that it would be useful just for some cases or projects., specially because it would consume too many resources. A way to turn this feature on/off per project would help the user when to turn it on/off.

[rchl]

You seem to be using VSCode and vscode doesn't use this language server. It has its own implementation that doesn't use the LSP protocol at https://github.com/microsoft/vscode/tree/main/extensions/typescript-language-features

That said, it was discussed previously in #253 in context of non-VSCode editors. The conclusion was that something like this is better implemented in the client (so opposite of the discussion you've linked ;)).

Even if we would decide that it belongs in the language server, I don't think the tsserver provides an API for compiling the whole project. So before anything could be done here, the typescript project would have to add that first. Though I imagine that would have to run in a separate process so that it doesn't block all the existing functionality as it would likely require quite a bit of time to compile some projects.

[niebloomj]

Thank you. I'll keep digging into this so I can figure out how we can best solve this issue. Thank you for your comment!

[rchl]

I've just realized that tsserver wouldn't need to expose any API. It could just send diagnostics for all files.

Sounds easy but the overhead of compiling the whole project on every change is likely what is gonna make this not very practical.

[entropitor]

@rchl And what if this is an option so clients have to opt-in (or even send a notification which will trigger sending all workspace diagnostics)?

The first build can take a while but after that, if you have project references + incremental builds turned on, builds can be super fast so I think it can be feasible for those cases and it would be a major win as seeing all errors in your editor is so useful!

[rchl]

There could be an option (typescript project usually adds options for the features it implements anyway). But in any case, it should be discussed in the typescript repo first IMO to figure out the best way forward.

[entropitor]

It seems to already be in tsserver: #361 This seems to be quite slow though so we still need to do it in the background and make sure we run it for all projects that are open but it seems to work already

[Rigo-m]

Any news on this? Unfortunately I'm new to this stuff, just started using nvim from vscode and cannot be of great help.
If someone has a working workaround i'd be glad <3

[andrewbanchich]

I also ran into this using Emacs. It's really difficult for me to work on any TypeScript project because of this issue. The whole point of a type system is to catch problems in the rest of your codebase, so I'm not sure what the point of only checking open files is.

Currently my workflow is to open a file, make a change, and then go back to the CLI to try to build it to see if there are errors anywhere else, which isn't ideal.

[dimitur2204]

Is there any progress on that? The only solution for nvim currently seems to be https://github.com/dmmulroy/tsc.nvim, which are not true diagnostics, but just a tsc --noEmit command thrown into a qflist it seems like