Use typescript-language-server instead of using javascript-typescript-langserver

[angelozerr]

Tody Eclipse Bluesky is using https://github.com/sourcegraph/javascript-typescript-langserver which implements LSP with TypeScript Language service.

IMHO, I think it should be better to consume https://github.com/prabirshrestha/typescript-language-server (once it will support all features like diagnostic, etc) which uses tsserver. Here pros to use it:

• it's a Microsoft guy who has developed that
• tsserver is hosted in the TypeScript bundle, so you will benefit of new features just by installing TypeScript bundle. For instance javascript-typescript-langserver doesn't support TypeScript plugins (see Support TS plugins sourcegraph/javascript-typescript-langserver#327). When
  typescript-language-server will support all feature like diagnotics ( Add textDocument/publishDiagnostics prabirshrestha/typescript-language-server#1) we will able to consume https://github.com/angelozerr/tslint-language-service or other plugins.

We must just wait for https://github.com/prabirshrestha/typescript-language-server consumes the whole tsserver commands.

[mickaelistria]

- it's a Microsoft guy who has developed that

It doesn't matter ;)

- tsserver is hosted in the TypeScript bundle, so you will benefit of new features just by installing TypeScript bundle. For instance javascript-typescript-langserver doesn't support TypeScript plugins (see sourcegraph/javascript-typescript-langserver#327 <sourcegraph/javascript-typescript-langserver#327>). When typescript-language-server will support all feature like diagnotics ( prabirshrestha/typescript-language-server#1 <prabirshrestha/typescript-language-server#1>) we will able to consume https://github.com/angelozerr/ tslint-language-service or other plugins.

That can be a convincing reason. But as long as the set of features supported by this LS is smaller that the one from current LS, it's not worth it. @felixfbecker: wdyt?

…

-- Mickael Istria Eclipse IDE <https://www.eclipse.org/downloads/eclipse-packages/> developer, at Red Hat Developers <https://developers.redhat.com/> community

[felixfbecker]

Awesome to see that MS is doing steps in the direction of LSP. I initially played around with just using TSServer, but that has some problems. To be clear, TSServer is just the RPC server that exposes the TS language service API. So in our language server, we expose the language server API directly over LSP, while in @prabirshrestha's, the language service API is first exposed through the TSServer RPC protocol, then that is proxied to LSP. There is no direct benefit to that other than less code is needed in the language server, but there are some disadvantages:

• LSP (or rather, JSON RPC) is more powerful than TSServer. By wrapping the TSServer RPC protocol, you inherit all of its disadvantages, namely inferior support for parallel requests and cancellation.
• LSP uses URIs, which allows it to work even in remote scenarios (over FTP etc) without accessing the file system. TSServer uses file paths
• At Sourcegraph, the language servers are run in a container which doesn't have the repo checked out on disk. Using the language service API directly, we can allow the language server to receive all contents over LSP. I couldn't get that to work with just TSServer, TSServer seems to always read files from disk. This ultimately was the reason why we decided to use the language service API directly.
• I would like to see the TS team slowly move towards LSP and at some point deprecate the TSServer. The TSServer RPC protocol is custom, only used for TS and harder to implement than LSP, which is built on the open JSON RPC standard. Still depending on the TSServer protocol under the hood doesn't seem like the right approach to me.

[prabirshrestha]

Although I'm a MS employee, typescript-language-server is my own pet project that I'm doing during my free time and has actually nothing to do with official MS working on it. I don't work in TypeScript team nor any of the tooling or language teams.

I'm one of those devs who still uses vim at work. I didn't find any good vim plugins for typescript that suits my needs ie, is purly async and works as first class plugin on windows (for work) and mac and linux (for OSS). I did discover LSP when researching so I decided to write the LSP plugin in vim first and use javascript-typescript-langserver. When I first started it didn't work in windows but I did report issues and has been fixed. In general most of the lang servers were very new and didnt support windows properly or had other issues, so I decided to take a break from it and instead work on other features like asyncomplete.vim that I could use for vim-lsp. Now that all those core features are done I'm back on making LSP work in vim. I really wanted to use javascript-typescript-langserver but the perf was not good enough so I decided to write a LSP wrapper around tsserver to check if it was a bug in my LSP vim plugin.

I don't think of typescript-language-server as a competitor to javascript-typescript-langserver. I think it is good to have a different implementation. Now there is a better way to validate performance for javascript-typescript-langserver. Currently I'm only interested in solving my problems which means my implementation would never support advanced features of what sourcegraph provides. That being said PRs are still welcomed since I really want to move to LSP. In fact I would most likely stop my development if its performance and support to disable partial requests are fixed and would give the ownership to anyone who is willing to maintain it further.

The main reason for using tsserver.cmd was that it was easier for me to use stdin/stdout because I was already familiar with it instead of learning the ts api. I use tscompletejob plugin in vim that uses tsserver.cmd underneath so I knew the perf wouldn't be bad.

To me I personally think typescript-language-server as an intermediate step until it gets replaced with javascript-typescript-langserver. Then I would like to see typescript deprecate tsserver and official support LSP. javascript-typescript-langserver is also very important to this because it brings quite a lot of requirements and learnings.

[angelozerr]

Thanks @felixfbecker @prabirshrestha to have taken time to answer us!

In my case, I'm studying if I could migrate TypeScript IDE and Angular Eclipse to LSP. I'm consumming tsserver and TypeScript plugins for angular support (completion, hover, etc inside Component/template) and compile on save. More you can choose the version of TypeScript runtime (generally you use the version of TypeScript runtime that user defines in their node_modules).

In other words I have the same architecture than VSCode. I would like keep that. I know with tsserver you benefit with those features that's why I like the idea of typescript-language-server. javascript-typescript-langserver seems more powerfull but I have the impression that your hard work (parallel request, etc) should be done on tsserver to avoid reinventing the wheel like tsserver.

@mickaelistria if you don't want to switch to typescript-language-server, do you think it should be possible to provide a preferences to choose the TypeScript LSP server?

[felixfbecker]

@angelozerr it would be great if you could express your desire at microsoft/TypeScript#11274 so Microsoft sees people want this :)

I am definitely not reinventing the wheel, the limitations rather come from the RPC protocol. So by switching to LSP you get these for free. See this architectural overview:

• Language Service: The "Language Service" exposes an additional layer around the core compiler pipeline that are best suiting editor-like applications. The language service supports the common set of a typical editor operations like statement completions, signature help, code formatting and outlining, colorization, etc... Basic re-factoring like rename, Debugging interface helpers like validating breakpoints as well as TypeScript-specific features like support of incremental compilation (--watch equivalent on the command-line). The language service is designed to efficiently handle scenarios with files changing over time within a long-lived compilation context; in that sense, the language service provides a slightly different perspective about working with programs and source files from that of the other compiler interfaces.
• Standalone Server (tsserver): The tsserver wraps the compiler and services layer, and exposes them through a JSON protocol.

https://github.com/Microsoft/TypeScript/wiki/Architectural-Overview

The only thing the TS langserver replaces is the TSServer part (yellow). All the intelligence is still done by the language service API. It is just a thin wrapper around the language service API, like TSServer itself. It just uses a different RPC protocol. If you want the benefits of LSP in the TSServer RPC protocol, you would have to turn it into LSP ;)

[angelozerr]

Thanks again @felixfbecker for your very complete answer!

@angelozerr it would be great if you could express your desire at microsoft/TypeScript#11274 so Microsoft sees people want this :)

Ok I will do that.

All the intelligence is still done by the language service API. It is just a thin wrapper around the language service API, like TSServer itself

tsserver provides plugins support (tslint, angular), compile on save support, ATA support, so it's not only a simple wrapper of language service API. It's the reason why I would like to use tsserver with BlueSky otherwise I could not provide the same feature with LSP BlueSky than TypeScript IDE and Angular Eclipse which consumes tsserver.

[felixfbecker]

There is a WIP PR for TS plugins: sourcegraph/javascript-typescript-langserver#327
It is only a matter of loading them into the language service.
I think ATA is in the language service too.
If you look at the architecture overview, TS will want all features to be supported by the VS Shim too, so whatever can be shared is added to the lower layer.

[angelozerr]

There is a WIP PR for TS plugins: sourcegraph/javascript-typescript-langserver#327
It is only a matter of loading them into the language service.

Yes I have seen that, but it's a sample of feature that you must reimplement it like tsserver.

It's very important for me to consume tslint and angular plugings otherwise I cannot to swith to LSP.

I think ATA is in the language service too.

There are some code inside tsserver for ATA https://github.com/Microsoft/TypeScript/tree/master/src/server/typingsInstaller

If you look at the architecture overview, TS will want all features to be supported by the VS Shim too, so whatever can be shared is added to the lower layer.

Yes sure, I would like just be sure to have the same feature than tsserver without waiting for some missing feature for several month @felixfbecker none offense with your great work!

[mickaelistria]

At the moment, there is no value for BlueSky to adopt another LS for JS/TS. So let's close this issue.
BlueSky can consider switching to another LS when there is a clear added-value for most users.

[angelozerr]

At the moment, there is no value for BlueSky to adopt another LS for JS/TS. So let's close this issue.
BlueSky can consider switching to another LS when there is a clear added-value for most users.

When I will try to support advanced features like compile on save or tslint/angular support, I will give you feedback

[angelozerr]

Just for your information an another tsserver wrapper https://github.com/theia-ide/typescript-lsp

[wsdjeg]

hmm get this issue from google, so which one should we use ? is there any user experience differences?