TSServer: Use JSON-RPC as RPC protocol (discussion)

[ianks]

Currently, TSServer uses its own protocol for RPC. The mechanics of it are fine and it does the job well. However, when it comes to implementing clients for TSServer, it is somewhat tedious to build wrappers specifically to interface with the TSServer protocol. Although it is fairly trivial thing to implement, it ends up being a unnecessary upfront cost to using TSServer (i.e. https://github.com/Microsoft/vscode/blob/master/extensions/typescript/src/utils/wireProtocol.ts)

As a client library user, this would be very helpful and would have saved me a significant amount of time when using TSServer.

As far as compatibility goes, the current protocol has a convention for RPC which looks like:

{ command: "someCommand", arguments: ... }

JSON-RPC would look something like:

{"jsonrpc": "2.0", "method": "someMethod", "params": ..., "id": 1}

As you can see, the serialization works out pretty favorably, and it would possible to actually support both JSON-RPC and the current protocol for a period of time to ease deprecation. If boilerplate is a concern, we could potentially even omit the jsonrpc key like xi-editor does.

Let me know your thoughts on this idea, and thanks for all the excellent work on Typescript!

[mhegazy]

Changing the protocol now means that every users of the server needs to change their serialization logic. so the only option is to add another protocol, and then maintain them as we go forward..

The server is exposed as both a node process, this one uses the JSON+contentLength messages as well as stdio for reading and writing. The server is also exposed as a library, see https://github.com/Microsoft/TypeScript/blob/master/lib/tsserverlibrary.js. This library has all the functionality without the node interaction. you can load it in your process, and customize the implementation. all you will need is to override the implementation of Session.send.

[icholy]

Possible duplicate #11274

[ianks]

so the only option is to add another protocol, and then maintain them as we go forward

@mhegazy Would it not be possible to deprecate the current protocol, support both serialization formats until the next major release, then drop support fort for the old protocol on the next major release?

[mhegazy]

@mhegazy Would it not be possible to deprecate the current protocol, support both serialization formats until the next major release, then drop support fort for the old protocol on the next major release?

it would. but that means that VSCode, VS plugin, sublimtext plugin, vim plugin, emacs plugin, eclipse plugin, etc.. have to all change their serialization. if I was in one of these plugin author shoes, i would not be happy about that.

[icholy]

if I was in one of these plugin author shoes, i would not be happy about that.

I wrote the TypeScript backend for YouCompleteMe and would definitely not be happy. If the protocol was changed, all clients would have to maintain both protocols if they wanted to be backwards compatible.

[ianks]

@icholy I am a bit confused since you seem supportive of #11274

Regardless, this issue can probably be closed in favor of that one.

[icholy]

@ianks IMO the trade-offs are worth it with the language-server-protocol as opposed to just changing the format.

[angelozerr]

@mhegazy do you think you will attention to support Language Server for TypeScript #11274

I'm really interested with this support since Eclipse IDE and Eclipse Che are implementing Language Server . It exists many Language Server like JSON, CSS but not for TypeScript -(

[mhegazy]

@mhegazy do you think you will attention to support Language Server for TypeScript #11274

I do not think we have talked about this specifically. A bit of a historical perspective. the TS LS protocol came first :) and then VSCode elaborated on it, and changed some things.

having said that, i do not see why not implement the protocol if there are consensuses around it. again, we will need to support this along with the current protocol, either through a configuration message to select the protocol version to use or some other mean.

[prabirshrestha]

I would be very interested in having Typescript officially support the language server protocol.

I have created an LSP client in pure vim script which works asynchronously in both vim and neovim. https://github.com/prabirshrestha/vim-lsp
It is currently being used by https://github.com/tjdevries/nvim-langserver-shim

[mhegazy]

As noted earlier, this would be a large breaking change, or a large tax to take. we would likely implement #11274 instead.