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.

Sign up for GitHub

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

Jump to bottom

Support closed-file diagnostics in VS Code #36664

Open
mjbvz opened this issue Feb 6, 2020 · 8 comments
Open

Support closed-file diagnostics in VS Code #36664

mjbvz opened this issue Feb 6, 2020 · 8 comments
Assignees
@RyanCavanaugh
Labels
Committed The team has roadmapped this issue Suggestion An idea for TypeScript

Comments

@mjbvz
Copy link
Contributor

mjbvz commented Feb 6, 2020

For microsoft/vscode#13953

Background

Project wide diagnostics are the most requested VS Code JS/TS feature. However, we"ve been blocked on implementing them by the fact that TS server is single threaded. This means that computing these diagnostics could interrupt normal user operations like completions.

We currently recommend that people use tasks to get around this limitation (since tasks always run as separate process) however few people actually use tasks.

With microsoft/vscode@f094278, I"ve added a new setting that spins up a new TS Server just for diagnostics. This accomplishes much the same thing as using a task.

Problem

In the prototype, I"m using the geterrForProject command. This works ok for smaller projects but triggers a huge number of events for larger projects like the VS Code source. Instead, we need an API that: given a file, returns a list of inverse dependencies (i.e. the files that need to be rechecked after the file changes)

I believe that this API more or less already exists with compileOnSaveAffectedFileList? But that command only works if compileOnSave is enabled. We"d like to enable project wide error reporting even when users have not enabled compileOnSave.

/cc @sheetalkamat For background on compileOnSaveAffectedFileList
/cc @amcasey As you suggested using a separate diagnostics only server
@mjbvz
Copy link
Contributor Author

mjbvz commented Feb 7, 2020 •
edited
Loading

Related question: before calling geterr on a file, do I always have to use updateOpen on it? Right now it seems like I have to explicitly open files against TS server in order to get back errors for them. Again, not ideal for larger projects

mjbvz added a commit to microsoft/vscode that referenced this issue Feb 7, 2020
@mjbvz
Prototype computing project wide errors using compileOnSaveAffectedFi…
73ef30f 
…leList

For #13953

Blocked by microsoft/TypeScript#36664
@RyanCavanaugh
Copy link
Member

@sheetalkamat thoughts?

@RyanCavanaugh RyanCavanaugh added the Suggestion An idea for TypeScript label Mar 2, 2020
@uniqueiniquity
Copy link
Contributor

uniqueiniquity commented Mar 2, 2020 •
edited
Loading

FWIW - @mjbvz and I met about this and I"m working on prototyping project-wide diagnostics more broadly than this particular ask

@RyanCavanaugh RyanCavanaugh added the Committed The team has roadmapped this issue label Mar 2, 2020
@amcasey amcasey changed the title TS Server command to get inverse dependencies of file Support closed-file diagnostics in VS Code Aug 10, 2021
@DanielRosenwasser DanielRosenwasser mentioned this issue Aug 30, 2021
Closed
@mjbvz mjbvz mentioned this issue Oct 4, 2021
Closed
@DanielRosenwasser
Copy link
Member

#15168 might be a relevant discussion point for this issue too.

@DanielRosenwasser
Copy link
Member

Instead, we need an API that: given a file, returns a list of inverse dependencies (i.e. the files that need to be rechecked after the file changes)

Yes, the first thing you want to see is errors from the current file ("what"s affected in this file?") and then that file"s dependents ("what did this file affect?"); however, when would you query for errors for the dependencies of the open files? (i.e. "what"s wrong with whatever this file depends on?")

@jerrygreen jerrygreen mentioned this issue Dec 28, 2021
Open
@amcasey amcasey assigned RyanCavanaugh and unassigned amcasey Nov 17, 2022
@sschafercdd
Copy link

I just turned on tsserver.experimental.enableProjectDiagnostics and it seems to give me what I expect. Files with Typescript errors show as red in the Explorer. So that"s nice.

But it does seem slow, and in general the error checking is just a bit sluggish. I might fix a syntax error but have to wait a second or two before it registers.

It does show the node_modules folder in red and appears to be checking that for errors despite that folder being excluded in tsconfig.json.

Seems like this issue has been open for a while, and it also seems like it would be fairly trivial to fix. So...can we get a fix for this?

@rodrigocipriani
Copy link

tsserver.experimental.enableProjectDiagnostics

Small fix, the right string on the settings.json is "typescript.tsserver.experimental.enableProjectDiagnostics": true

@dallman2
Copy link

dallman2 commented Aug 8, 2023

Is there an expected time to completion on this issue? It would be nice to see what breaks in my codebase when changing lint rules, or just refactoring types...

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

@RyanCavanaugh RyanCavanaugh

Labels
Committed The team has roadmapped this issue Suggestion An idea for TypeScript
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
9 participants
@DanielRosenwasser @rodrigocipriani @RyanCavanaugh @sheetalkamat @uniqueiniquity @amcasey @mjbvz @sschafercdd @dallman2