Usage with typescript-language-server

[dlvhdr]

I would like to use this library to improve my project's typescript intellisense.
I've looked at a lot of different options and it seems like this library is my best bet.
You really did an amazing job and having it open source is really appreciated.

TDLR is that I want to understand if there are any major gotchas, risks and generally stuff that will make integrating this into Wix easier...

I'm including your answers from the email discussion we had.
Regarding the questions in the TLDR, you replied with:

• Provider a server for every single user is very resource consuming, we had to build a way to mutualize a language server for multiple users
• Everything is built for vscode, so there some hack required (The whole lib is kind of a hack, even if it's a little less true since the v2), including:
  • vscode-languageclient itself, which uses functionalities from vscode that monaco doesn't support (We disabled them by default)
  • LanguageClient is meant to be used inside a vscode extension, and extensions often customize the protocol (adding custom requests) and the interface with vscode (implementing language feature by hands)

My Proposed Architecture

Questions

1. I would love to know if, for CodinGame, you went with a server so you can use the full power of tsserver and if so, have you explored client-side only solutions?

2. Are you using monaco and not something like Gitpod's vscode server to compose a custom UI that fits your uses?

3. You said:

   Provider a server for every single user is very resource consuming, we had to build a way to mutualize a language server for multiple users

   By "language server" do you specifically mean something like typescript-language-server?
   Or do you mean you're sharing one actual server that just exposes multiple endpoints for users to connect via web socket?
   With that solution, you'd still run multiple tsserver processes, right?

4. Have you also implemented something like a file tree that connects with monaco? Would that be done by providing custom services to monaco?

Thanks for taking the time!

My understanding of monaco-languageclient

I'll just dump my understading of monaco-languageclient here for future readers.

• The https://github.com/microsoft/vscode-languageserver-node repo contains several packages.
  One of which is vscode-languageclient.
• The vscode-languageclient package, exposes a BaseLanguageClient class that can easily be extended.
• This BaseLanguageClient class is how you can create language server extensions (See the official VSCode guide)
  It exposes the start(), stop() and createMessageTransports() methods.
  View the code
• The monaco-languageclient package simply inherits from the same BaseLanguageClient class but provides a different implementation for the protected method createMessageTransports.
• The new createMessageTransports provides the reader and writer that we created, and those are connected to our WebSocket directly.
• monaco-languageclient then registers all the language features from vscode-languageclient. These are the same features used in VSCode.
  View the code
• These language features send messages over the given transports (the socket basically) so everything just works. They are taken directly from the Typescript extension for VSCode.
  View the code
• monaco-languageclient overrides the vscode package and provides https://github.com/CodinGame/monaco-vscode-api instead. This library implements the VSCode api and redirects calls to Monaco editor.

[CGNonofr]

I would love to know if, for CodinGame, you went with a server so you can use the full power of tsserver and if so, have you explored client-side only solutions?

Monaco editor provides a client worker for typescript/javascript (and some others) and we use it. We also use a real TypeScript language server on apps with more requirements (to add libraries, to add angular extension)
There is also a solution to include a language server in a client worker, it's a pretty new concept, developed for the web version of vscode I think, there is almost no available implementation and we never really investigate this approach for the moment

• Are you using monaco and not something like Gitpod's vscode server to compose a custom UI that fits your uses?

We are using Monaco because we just need an editor. I don't know about the complexity of building such UI on vscode server

By "language server" do you specifically mean something like typescript-language-server?

Yes, we're sharing a single process across multiple users, each user in their own "workspaceFolder"

Have you also implemented something like a file tree that connects with monaco? Would that be done by providing custom services to monaco?

At one place only. And monaco is not the source of truth, firebase is. So we're just creating and disposing models as we need them or not.

I'll just dump my understading of monaco-languageclient here for future readers.
...

Everything seems to be clear to you :)

[kaisalmen]

There is also a solution to include a language server in a client worker, it's a pretty new concept, developed for the web version of vscode I think, there is almost no available implementation and we never really investigate this approach for the moment

@CGNonofr Our newest example (https://github.com/TypeFox/monaco-languageclient/tree/main/packages/examples/browser-lsp) makes use of this concept or do you mean something else here?

[CGNonofr]

That's what I meant!

[dlvhdr]

Thanks a lot for the answers :)
I have a few more if you don't mind!

• In addition to having 1 language-server serve multiple users with the workspaceFolders trick, are you also running multiple language-servers in one container / backend server?
• Did you implement something like tab management? Is that done by providing a less naive TextModelService to monaco? I'm guessing this has nothing to do with monaco-languageclient but is a separate challenge.
• Are you also running more language servers using the same infra? Stuff like eslint, prettier, JSON, CSS language servers etc.
• Are there any plans of moving monaco-vscode-api to TypeFox?

I might have a couple more questions as we start implementing this, especially on the backend side, so sorry about that!
But it's really helpful 🥇

[CGNonofr]

• one container = one language server, but there is many containers on the same server
• I'm not sure what you mean, are you talking about doing a ctrl+click on an import an expect a new tab to be open with the imported file?
• You can start as many language servers in parallel as you want, we don't use this possibility for the moment but it'll come
• I don't work at TypeFox, and we're using monaco-vscode-api for other things than monaco-languageclient, what would be the point?

[dlvhdr]

Thanks!

I'm not sure what you mean, are you talking about doing a ctrl+click on an import an expect a new tab to be open with the imported file?

Yes exactly.

I don't work at TypeFox, and we're using monaco-vscode-api for other things than monaco-languageclient, what would be the point?

Oh I just thought TypeFox is the parent company of CodinGame because I thought I saw monaco-languageclient moved there from CodinGame. There's no real point here, just was curious :)

My colleague had another couple of question:

• How can we notify to the server that a new file has been added from the client?
• If we add a file on the server and we want to update the client, how does that work? Something like a rename refactor, or maybe we added a new generated file when something happens (like a d.ts file etc)

[CGNonofr]

Yes exactly.

Monaco version of the services are too simple indeed. That's why I recently added the service-override functionality to monaco-vscode-api (take a look at the readme of monaco-vscode-api)

It allows to override the simple monaco service by the original vscode one. It's done for the messages (notifications/dialogs) and the model/editor management. You provide a callback which is called with the new created model and you return the editor displaying it.

Oh I just thought TypeFox is the parent company of CodinGame because I thought I saw monaco-languageclient moved there from CodinGame. There's no real point here, just was curious :)

Not at all, TypeFox created this project at first, we were using it a lot at CodinGame. Then TypeFox kind of abandoned the project and I became the main contributor. I was planning to move to the CodinGame fork when TypeFox came back to contributing to the project.

How can we notify to the server that a new file has been added from the client?

Not really clear, if you are talking about the didOpen notification, nothing has to be done. If you are talking about filesystem management, you have to handle it by hands.

If we add a file on the server and we want to update the client, how does that work? Something like a rename refactor, or maybe we added a new generated file when something happens (like a d.ts file etc)

I don't think it's specific to this lib but the language server implementation itself, what do you mean by update the client?

[dlvhdr]

Thanks for taking the time, I feel a bit like I'm interrogating you for your knowledge so sorry about that :)

Monaco version of the services are too simple indeed. That's why I recently added the service-override functionality to monaco-vscode-api (take a look at the readme of monaco-vscode-api)
It allows to override the simple monaco service by the original vscode one. It's done for the messages (notifications/dialogs) and the model/editor management. You provide a callback which is called with the new created model and you return the editor displaying it.

I've actually went ahead and built the repo since that version is not out on NPM yet.
Since I'm using a Mac I had to make small modifications to the build script. Do you want me to contribute it?

I don't think it's specific to this lib but the language server implementation itself, what do you mean by update the client?

When we for example rename a symbol, and the language server creates a textDocument/rename LSP message, does monaco know to update all the relevant open models?

[kaisalmen]

Not at all, TypeFox created this project at first, we were using it a lot at CodinGame. Then TypeFox kind of abandoned the project and I became the main contributor. I was planning to move to the CodinGame fork when TypeFox came back to contributing to the project.

@CGNonofr kept this project alive and has the deepest knowledge. 💪 After the initial contributors from TypeFox focused on Gitpod we basically neglected it for almost two years. Gitpod developed into a success story and it became a separate company in the meantime. We at TypeFox realized at some point that this library is really helpful and that we should start contributing again. That's when I showed up (#315) 🙂