4.1.0: didOpen fails for .tsx with "Cannot open document"
rajeevn1 opened this issue · comments
reverting back to 4.0.0 solves the issue.
4,1.0 seems to work for .ts files.
I'm experiencing a similar issue with ".ts" files in my Emacs environment using version 4.1.0. When I revert back to version 4.0.0, everything works as expected. I haven't tried ".tsx" files.
Here's the error message I'm receiving:
[server-reply] (id:24) ERROR Mon Nov 13 08:57:20 2023: (:jsonrpc "2.0" :id 24 :error (:code -32603 :message "Request textDocument/documentHighlight failed with message: The document should be opened first: file://[my-file-path]")) [internal] (id:24) ERROR Mon Nov 13 08:57:20 2023: (:message "error ignored, status set (Request textDocument/documentHighlight failed with message: The document should be opened first: file://[my-file-path])" :id 24 :error -32603)
That's likely because your client (Emacs, etc) sends incorrect language ID for those files.
These are the language IDs that should be set for each file type:
js - javascript
ts - typescript
jsx - javascriptreact
tsx - typescriptreact
Previous version of the server was less strict but that likely caused hard to spot issues at a later point.
If you look at the textDocument/didOpen request then you'll see what languageId is being passed.
@rchl Is there a reason the server can't infer this on its own? It does have the file name after all.
It would in theory but what would the point of the languageId specified in the LSP spec be then? Why should the server try to fix client or user errors? Especially since it should be easily fixable on the client side.
In Kate, we have work around a lot of issues that are actually server issues because we don't have much of a choice besides letting it fail and let the user suffer.
My point is that rather than breaking perhaps a better idea is to keep a fallback. This matters for some clients like us because we ship once in 4 months. If a server breaks in between releases like this, then an average user is just stuck with a broken server till the next release. Oh and if you are on UbuntuLTS or something like that, then good luck.
Oh and if you are on UbuntuLTS or something like that, then good luck.
Though neither Kate nor this server are part of Ubuntu so that shouldn't really be relevant. :)
I will look into adding a fallback when languageId is wrong.
Its not a part of Ubuntu, but it is installable on Ubuntu. Thanks for listening :)
Hello,
That's likely because your client (Emacs, etc) sends incorrect language ID for those files.
These are the language IDs that should be set for each file type:
Where is a client author to get this information from? This thread? Or is it some universal information published somewhere.
Is this for all TS servers or just this one? My Eglot client has been providing tsx and js for a long time and it has always worked.
It would in theory but what would the point of the languageId specified in the LSP spec be then?
I assume it's for when files exist in a given language have non-standard extensions so the server can't possibly guess from.
Especially since it should be easily fixable on the client side.
Not really: the client often doesn't know much more about the file's intented language than the server. If
anything, it knows less (the server is the language specialist who could look at the file's contents).
Also this leads to hardcoding things on the client side, which at least my client specifically avoids (it works with hundreds of LSP servers and virtually no server-specific code).
But I see you've already pushed a commit that fixes this, at least for the time being.
So thanks.
Where is a client author to get this information from? This thread? Or is it some universal information published somewhere.
The official spec lists those relevant to this server at least: https://microsoft.github.io/language-server-protocol/specification#textDocumentItem
Is this for all TS servers or just this one? My Eglot client has been providing tsx and js for a long time and it has always worked.
Previously the server didn't validate language ID but then the tsserver would receive wrong languageId and not be able to tell the type of the code apart and likely result in some things not working as expected.
Not really: the client often doesn't know much more about the file's intented language than the server. If anything, it knows less (the server is the language specialist who could look at the file's contents).
Also this leads to hardcoding things on the client side, which at least my client specifically avoids (it works with hundreds of LSP servers and virtually no server-specific code).
The client should know the syntax of the file and thus the language type. Clients should maintain a mapping from syntax/scope to languageId.
While it might not apply so much to this server since this one is geared towards normal files, many servers can work on unsaved files that don't have extension and then the only way to tell the language of the file is with the syntax/languageId.
So relying on file extension alone is not reliable.
The official spec lists those relevant to this server at least: https://microsoft.github.io/language-server-protocol/specification#textDocumentItem
Thanks, I missed this.
In Kate, we have work around a lot of issues that are actually server issues because we don't have much of a choice besides letting it fail and let the user suffer.
My point is that rather than breaking perhaps a better idea is to keep a fallback. This matters for some clients like us because we ship once in 4 months. If a server breaks in between releases like this, then an average user is just stuck with a broken server till the next release. Oh and if you are on UbuntuLTS or something like that, then good luck.
yeah i use kate and had to downgrade and ignore upgrades for the typescript-language-server package on arch because of this update :/
oh nvm i just saw that the fix just requires editing the LSP config, also made a pr to fix lol