Plugin incompatible with built-in tsserver enableProjectDiagnostics
#437
Labels
enhancement
New feature or request
Comments
|
I can't reproduce by your example. Maybe we need more info. I suggest,
And you missed OS information. It would be nice to have one because there can be platform issue. |
|
The first step is what does |
|
Ok it's very very verbose! So this is just the output from when I type the Not sure if that is very helpful... |
|
Here is the output with the original document (with I edited some lines where the log includes the entire contents of enormous files (you may want to change your JSON printing routing to elide long strings). |
Closed
|
There have been some changes to the extension recently that provide slightly more information. If the issue is still a problem, please ensure the extension is updated (along with the version of Deno) and provide the output of at least the first section of the document that opens when doing Deno: Language Server Status from the command pallette. |
|
Here you go: Deno Language Server StatusWorkspace Settings{
"enable": true,
"cache": null,
"config": null,
"importMap": null,
"codeLens": {
"implementations": false,
"references": false,
"referencesAllFunctions": false,
"test": true
},
"internalDebug": true,
"lint": true,
"suggest": {
"completeFunctionCalls": false,
"names": true,
"paths": true,
"autoImports": true,
"imports": {
"autoDiscover": true,
"hosts": {}
}
},
"unstable": true
}Workspace Details
Performance
|
|
What do you have in |
|
I don't have those documents open in my editor. |
|
Well somehow the are getting opened. Information you provided indicates those documents are in memory and also the previous information on the debug trace you can see that How are you starting VSCode. If you don't open a workspace, you can get some strange behaviours. Could you possibly be starting vscode like this? Instead of: If this occurs, and you have a |
|
Hmm I suspect they might have been open in a different VSCode window. Either way, I closed all the VSCode windows, restarted it, and this bug still happens even though those documents are no longer open. (And I don't see why they would matter anyway.)
Like I don't have a This is really easy to reproduce for me but it sounds like you are a bit skeptical that it happens - can you reproduce it? Deno Language Server StatusWorkspace Settings{
"enable": true,
"cache": null,
"config": null,
"importMap": null,
"codeLens": {
"implementations": false,
"references": false,
"referencesAllFunctions": false,
"test": true
},
"internalDebug": true,
"lint": true,
"suggest": {
"completeFunctionCalls": false,
"names": true,
"paths": true,
"autoImports": true,
"imports": {
"autoDiscover": true,
"hosts": {}
}
},
"unstable": true
}Workspace Details
Performance
|
No. The only way I could reproduce it is the way I mentioned above, there I launched it from the command line giving a specific file (e.g. |
|
Hmm interesting. Ok I'll try it on a couple of different machines. Are you using a Mac? |
|
Finally figured it out. I have this in my VSCode settings: Without that setting it works (though I'd like to keep that setting!). |
kitsonk
changed the title
enableProjectDiagnostics
|
That setting specifically tells tsc to report issues across all files not open in the editor, which means that the plugin we use to "mute" diagnostics for Deno enabled projects is bypassed. It might be possible to change the plugin to support that, but it may not be easy to do. Instead of setting it globally, I would set it on a per project basis, and only for projects that are not Deno enabled. |
|
Maybe set it to false when you run the "Initialise Deno" command? |
|
We don't adjust other plugin settings. |
|
It's not actually a plugin - it's built in to VSCode. Also, why not? |
|
It is a plugin/extension. Just one that us included and enabled by default and can be disabled as well. Because, it tightly couples the Deno extension to other extensions. Deno does not "own" other extension settings and modifying them is dangerous. Plus, we would have to modify it based on the The plugin API we use in the language server to mute the diagnostics is an officially supported way to change the behaviour of the builtin tsserver extension. |
|
Hmm, is it at least possible to detect if that option is set and display a warning? You must agree that not doing anything is not a good solution? This problem was very difficult to track down. |
|
As I stated previously:
It is tagged as an enhancement and the issue is open. |
|
In order to fix this, we have to re-engineer how mutating diagnostics occur when |
|
It looks like the diagnostics that result from this setting are from a separate TS server, which we have no access to in the plugin. https://github.com/microsoft/vscode/blob/bccfade64adb249f57c8fcf03cba41609f76ce5c/extensions/typescript-language-features/src/tsServer/spawner.ts#L67 |
|
Is there any update on this? I use |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Edit: From #437 (comment):
Original post:
The Deno VSCode extension doesn't seem to work at all for me. It acts the same as I would expect from the Typescript extension with the default
tsconfig.json. For example it doesn't know aboutDeno, it complains about iterating over collections, usingPromise<T>and so on. I have demonstrated the simplest error below.To Reproduce
Screenshots
Versions
vscode: 1.56.2
deno: 1.10.3
extension: 3.5.1
The text was updated successfully, but these errors were encountered: