[WIP] Introduce LSP mode for TSServer with some initial functionality

[uniqueiniquity]

First step towards fixing #39459.
This PR targets the feature/lspSession branch, since we will likely want to implement the full LSP mode over the course of several PRs.

Here, we introduce a new command-line flag --useLsp for TSServer that allows it to communicate with a client via the Language Server Protocol.

To do so, we introduce two new projects: one in the src/jsonrpc folder that implements reading and writing of the JSON-RPC protocol over Node streams (based on the implementation of vscode-jsonrpc), and the other in the src/uri folder that implements parsing and formation of standard URIs (based on the implementation of vscode-uri).

Given these new utilities, we are able to implement a new subclass of NodeSession called LSPSession. In contrast with our existing IOSession, which uses our own custom message protocol, LSPSession uses the Language Server Protocol to communicate with a consuming client. When a message is received and its contents parsed into objects of LSP spec types (defined in src/server/lspProtocol.ts), it is handled by the corresponding method handler defined in src/server/lspHandlers.ts.
Note that when messages are received, they are explicitly queued as part of the Node.js poll phase (where I/O is handled), then processed as part of the Node.js check phase (where setImmediate callbacks are invoked). This allows LSP cancellation messages to be received in order to cancel requests that have not yet been handled.

At this stage, we have implemented handlers for the following LSP messages:

• initialize
• initialized
• shutdown
• exit
• textDocument/didOpen
• textDocument/didChange
• textDocument/didClose
• textDocument/hover
• textDocument/signatureHelp

To validate the changes made to the Session class and the implementations of the LSP handlers, we have implemented a TestLspSession class (to be compared with the existing TestSession) that can be used to write unit tests for LSP functionality. Such tests are provided here for the hover and signature help features in the src/testRunner/unittests/tsserver/lsp folder.

[amcasey]

Why is prepend needed?

[uniqueiniquity]

It may not be 😅

[rchl]

To do so, we introduce two new projects: one in the src/jsonrpc folder that implements reading and writing of the JSON-RPC protocol over Node streams (based on the implementation of vscode-jsonrpc), and the other in the src/uri folder that implements parsing and formation of standard URIs (based on the implementation of vscode-uri).

I wonder why it was necessary to re-implement those. Despite the name, those packages are used by most if not all JS/TS-based language servers and are compatible with any editor.

EDIT: Looked at the changes and vscode-uri is actually used.

[ShuiRuTian]

A small question, why not enum?

[Spoutnik97]

Is there a plan to merge this ?

[amcasey]

Ben and I have both been off the team for several years, but I think @jakebailey might be looking into this?

[jakebailey]

Yes, it's on my list, though I don't think this PR itself will be a part of it directly.

[Spoutnik97]

Do you already have PR to follow your work?

I am a Zed user, and typescript lsp is very slow versus tsserver...

[jakebailey]

No, not yet. But that LSP wrapper is more or less the same as tsserver so not sure why you'd have a performance difference.

[Spoutnik97]

This is what this issue seems to think : zed-industries/zed#5166

[brunogrcsada]

I think there's probably some crossed wires there - other editors like Helix which do use the LSP wrapper don't seem to have the same massive delay on returning results.

It definitely seems to be a lot more prominent in larger monorepos, which makes me think it's related to an IO issue

Sure, cleaner LSP bindings that are supported directly by the team would be great, but I don't see why there would be such a big disparity compared to tsserver