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

Closing file does not cause TS to remove errors related to that file #59363

Closed
aaroncraig10e opened this issue Sep 25, 2018 · 6 comments
Closed
Assignees
Labels
bug Issue identified by VS Code Team member as probable bug javascript JavaScript support issues typescript Typescript support issues verified Verification succeeded
Milestone

Comments

@aaroncraig10e
Copy link

Issue Type: Bug

Open a file in VSCode Insiders with TS errors (such as a .ts or .tsx file).
Note that the errors are reported in the Problems pane
Close the file with cmd+w
Note that the errors are persisted in the Problems pane -- a window reload is required to get them to disappear

Possibly related to #58088
Also related to this issue: #50448

VS Code version: Code - Insiders 1.28.0-insider (29e6795, 2018-09-24T12:04:09.319Z)
OS version: Darwin x64 17.7.0

System Info
Item Value
CPUs Intel(R) Core(TM) i7-7820HQ CPU @ 2.90GHz (8 x 2900)
GPU Status 2d_canvas: enabled
checker_imaging: disabled_off
flash_3d: enabled
flash_stage3d: enabled
flash_stage3d_baseline: enabled
gpu_compositing: enabled
multiple_raster_threads: enabled_on
native_gpu_memory_buffers: enabled
rasterization: enabled
video_decode: enabled
video_encode: enabled
webgl: enabled
webgl2: enabled
Load (avg) 7, 5, 5
Memory (System) 16.00GB (0.62GB free)
Process Argv -psn_0_3752852
Screen Reader no
VM 0%
Extensions (29)
Extension Author (truncated) Version
Bookmarks ale 9.1.0
project-manager ale 9.0.0
vscode-eslint dba 1.6.0
javascript-ejs-support Dig 0.3.2
githistory don 0.4.2
gitlens eam 8.5.6
tslint eg2 1.0.39
prettier-vscode esb 1.6.1
vscode-pull-request-github Git 0.1.6
jenkins-declarative-support jmM 0.1.0
terraform mau 1.3.5
dotenv mik 1.0.1
python ms- 2018.8.0
atom-keybindings ms- 3.0.4
azure-account ms- 0.4.3
vsliveshare ms- 0.3.709
debugger-for-chrome msj 4.10.1
vscode-jest Ort 2.9.0
vscode-docker Pet 0.3.0
material-icon-theme PKi 3.6.0
ruby reb 0.20.0
java red 0.31.0
jenkinsfile-support sec 0.1.0
slack soz 0.0.14
code-spell-checker str 1.6.10
vscode-java-debug vsc 0.13.0
vscode-java-test vsc 0.9.0
vscode-react-native vsm 0.6.17
markdown-all-in-one yzh 1.6.2

(6 theme extensions excluded)

@vscodebot vscodebot bot added the insiders label Sep 25, 2018
@aaroncraig10e
Copy link
Author

I have a screen capture of this behavior which I'm happy to share privately with the devs, if that's helpful.

@mjbvz
Copy link
Collaborator

mjbvz commented Oct 22, 2018

@dbaeumer @alexr00 This is currently by-design (see #47386)

What we want is:

  • If you close a file and there is no tsc task running, we clear the errors for that file
  • If you close a file and there is a tsc task running, the tsc errors replace the typescript extension errors

Anyway to achieve this?

@aaroncraig10e
Copy link
Author

Any particular reason this is the desired behavior?

It seems at the very least that this should be configurable. As it stands, all of the other plugins that report errors clean up their output when a file is closed.

Clearly some teams prefer this behavior, but it seems a fairly obvious thing that has legitimate arguments either way. Any way we could get a setting to configure the behavior we want?

@vscodebot vscodebot bot removed the insiders label Oct 23, 2018
@dbaeumer
Copy link
Member

@mjbvz our recommendation for language providers so far is different and independent of a build task. What we recommend is the following:

  • single file language like linters should compute errors on file open and clear them on file close. Reason is that these languages usually don't have a project context.
  • multi file languages with project file:
    • on project open compute all errors
    • on project close remove all errors
    • on file open reconcile the file and compute errors

A very good implementation of this is the C# extension (see my screen shot which shows two errors although no file is open. I didn't even open any file :-))

capture

The TypeScript language server never had good support to compute all problems of a project. But this might have changed with 3.0 and there builder support. That is why we bound the error computation in TypeScript to an external build task with problems of restoring them correctly. I have an issue for this and targeted it for November. I would also recommend to look into whether the TS language server got better in computing all errors for a project.

I am also open to reconsider this general recommendation. But we need good arguments if we want to change this since it will influence other extensions as well. The worst IMO will be if every extension does something different.

@Astrantia
Copy link

@mjbvz Any news regarding this? My js file errors are never getting cleared after closing them and there are no tsc tasks running.

@pmkroeker
Copy link

Could we add an option to remove the files manually? Like having a context menu option that removes problems from the selected file?

@mjbvz mjbvz added bug Issue identified by VS Code Team member as probable bug typescript Typescript support issues javascript JavaScript support issues labels Feb 21, 2019
@mjbvz mjbvz added this to the February 2019 milestone Feb 21, 2019
@mjbvz mjbvz closed this as completed in 553e6e4 Feb 21, 2019
sandy081 pushed a commit to vldmrkl/vscode that referenced this issue Feb 22, 2019
@jrieken jrieken added the verified Verification succeeded label Feb 26, 2019
@vscodebot vscodebot bot locked and limited conversation to collaborators Apr 7, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Issue identified by VS Code Team member as probable bug javascript JavaScript support issues typescript Typescript support issues verified Verification succeeded
Projects
None yet
Development

No branches or pull requests

6 participants