As the language server protocol ( https://github.com/Microsoft/language-server-protocol ) is getting more and more popularity and clients ( https://github.com/Microsoft/language-server-protocol/wiki/Protocol-Implementations ), it would be very useful to have the tsserver implement this protocol.
Been 2 monthts, any updates?
We did some work at Sourcegraph in wrapping the TS language service as a language server, but hit some limitations with the current API. Specifically, the LanguageServiceHost
interface you can provide to the server requires the methods that return file contents to return synchronously. In a language server however this is most likely done asynchronously because retrieving the file content involves IO with the file system or over the protocol stream.
I would be very interested in help or improvements in the TS server to solve this use case.
@felixfbecker Would it be possible to overcome the limitations if you interfaced with an instance of tsserver instead?
@masaeedu I don't understand the question - the TS language server is using the LanguageService
from TypeScript?
@felixfbecker Sorry, I'll try to clarify what I mean. Instead of implementing LanguageServiceHost
, you could let tsserver
host the language service, and you wouldn't need to care about how it satisfies that interface. Your language server process would rely on passing messages to/from tsserver, which is inherently async.
@masaeedu wouldn't the tsserver try to read from the file system directly?
@felixfbecker Yeah, it would read the files directly. I don't think that would affect your language server process in any way though. If/when they make performance improvements to tsserver you don't need to make any changes.
@masaeedu That is a dealbreaker unfortunately, because the files are not available locally in the container.
I have implemented the initial version of language server protocol for typescript which can be found at https://github.com/prabirshrestha/typescript-language-server. It acts as a proxy for tsserver
. Currently textDocument/didOpen
, textDocument/change
and textDocument/completion
are implemented but adding others should be fairly easy.
In the long term I would definitely love to see LSP shipping as part of the official typescript installation.
Here is another LSP implementation of Typescript based on my original tsserver proxy idea. https://github.com/theia-ide/typescript-language-server. They have added more protocol feature support. It is maintained by folks at TypeFox. I have also handed over the typescript-language-server
npm package to them.
https://github.com/Microsoft/TypeScript/wiki/Roadmap#30-july-2018
I saw the roadmap. next version up is major version up! 馃
do you have any plans about this issue?
Can we get an update on whether there are plans for this issue?
The two existing TS LSP servers both have big issues. If the TS team wants TypeScript to be used outside of VSCode / VStudio, they should resolve this issue.
SourceGraph: worst-case warm-up time is extremely long; no support for files that change on disk, such as the tsconfig.json file.
TypeFox: incomplete implementation of LSP.
6 months from the time last comment was written. Any updates on this? LSP is promoted by Microsoft, yet TypeScript seems to ignore it. Weird :-)
You can use https://github.com/theia-ide/typescript-language-server which more or less does the work of wrapping tsserver messages as LSP ones.
I'm closing this issue as I'm satisfied with https://github.com/theia-ide/typescript-language-server and wouldn't -as a consumer- get.any clear added-value if this were implemented directly in tsserver.
I am using https://github.com/theia-ide/typescript-language-server too and it has lots of problems. Problems that I think wouldn't exist if the official server spoke LSP.
The library of theia-ide seems to be not bad, but as felixbecker said, indeed has problems, unfortunately. For instance it does not raise errors on unused variables when noUnusedLocals
is enabled. And I have just started exploring it (fearing of other inconsistencies).
Make sure those bugs are reported to typescript-language-server andthey'll
evntually be fixed.
--
Mickael Istria
Eclipse IDE https://www.eclipse.org/downloads/eclipse-packages/
developer, for Red Hat Developers https://developers.redhat.com/
One more anecdote is https://github.com/Microsoft/vscode/issues/70239
By not using LSP in tsserver, it means there are features that exist in vscode + tsserver that aren't yet possible to implement with LSP + vscode alone. This puts LSP implementations at a disadvantage compared to non-LSP implementations.
I'm also using https://github.com/theia-ide/typescript-language-server . But I found it's looking for maintainers. theia-ide/typescript-language-server#141 I think it shows we can't rely on it so long time.
Is it the time to reconsider this issue?
It would be great if typescript embraces LSP and makes sure that features are available through it when they are added. That's VS Code uses tsserver directly without using LSP put all other tools to disadvantage. That's one of reasons for Theia to use VS Code extensions instead of trying to align https://github.com/theia-ide/typescript-language-server with VS Code extension each release.
This request means additional work for the TS team, and VSCode's tight integration with TSServer makes a subtle to hint to use another Microsoft product. But not doing it leaves influence on the table. There are many people that can't or won't use VSCode, but will use LSP. Neovim's upcoming LSP client for example.
So, what's the status of this?
There isn't any updated and maintained language server for JS / TS currently, as far I know
See #39459 which revives this issue in this new context.
Most helpful comment
Can we get an update on whether there are plans for this issue?
The two existing TS LSP servers both have big issues. If the TS team wants TypeScript to be used outside of VSCode / VStudio, they should resolve this issue.
SourceGraph: worst-case warm-up time is extremely long; no support for files that change on disk, such as the tsconfig.json file.
TypeFox: incomplete implementation of LSP.