feat: support client-side fallback mode with WS reconnect for LSP recovery

[ls-infra]

Hi team,

Is there any configuration or built-in mechanism to make the WebSocket (WS) connection optional?

Ideally, when the WS connection is unavailable or temporarily down, the editor could continue functioning in a client-side–only mode (without LSP features). For example, libraries like ngx-monaco-editor allow Monaco to run purely on the client side without requiring a persistent WS connection.

Once the WS connection is restored, it could automatically reconnect and resume LSP features such as diagnostics and code compilation.

This would improve resilience and ensure the editor remains usable even when the WS backend is temporarily unavailable.

If this is not currently supported, I’d be happy to contribute a PR if you could provide some guidance on the recommended approach or design direction.

Thanks!

[CGNonofr]

I don't think the language client having errors makes the editor non-functioning, you will just lose the intellisense features 🤔 Am I missing something?

[ls-infra]

Thanks for the clarification.

What I’m aiming for is a true client-side-only mode in certain scenarios (e.g. when backend capacity is limited). In those cases, I’d prefer to initialize Monaco without establishing a backend WebSocket connection at all (i.e. skip wrapper.start()).

This becomes particularly important in a multi-tenant setup, where we may have many users online at the same time, and each user can open multiple Monaco editors concurrently. If every editor instance automatically establishes its own LSP WebSocket connection, it can easily overload the backend. Having a configurable client-side-only mode (or a controlled connection strategy) would help prevent excessive LSP connections and better protect backend capacity in a more scalable design.

Currently, if we omit start(), the editor instance becomes undefined in wrapper.getEditor() later. It would be helpful if we could introduce a config option (e.g. clientSideOnly) in WrapperConfig that allows init() to run without connecting to the backend.

Additionally, when navigating away from the page, I’d like to ensure the WS connection is fully closed. Would calling await wrapper.dispose() be sufficient? From what I can see, it sends the shutdown and exit JSON-RPC messages to the server.

{"jsonrpc":"2.0","id":3,"method":"shutdown"}
{"jsonrpc":"2.0","method":"exit"}

One more point: we also have await wrapper.disposeLanguageClients(), but it doesn’t accept editor IDs. In scenarios where multiple Monaco LSP connections exist on the same page, it would be useful to close a specific LSP connection rather than all of them.

[ls-infra]

https://github.com/TypeFox/monaco-languageclient/blob/main/packages/client/src/wrapper/lcwrapper.ts#L63
the new WebSocket instance is inside this .start method ,
can we make it class level instance so we can call the .close method (in which calls this.webSocket.close();)

the currently .dispose method does not seem to call .close to disconnect the WebSocket

[kaisalmen]

Hi @ls-infra the langauge clients are globally registered and their life cycles can be independently managed. The decoupling of monaco-vscode-api, language clients and editor was realized with mlc v10.
For example:
https://github.com/TypeFox/monaco-languageclient/blob/main/packages/examples/src/python/client/main.ts
makes use of the Views Service and the language server support is available for any new editor as it globally registered. The mechanism applies to multiple editors created with EditorService as well. What I am after is that you can and should managed your language client connection on application level and not editor level.

Regarding closure and restart behaviour of the web socket connection there is need for improvement / app level tests are needed to prove our implementation behaves as expected. I need to investigate your last question.
I started to work on that and other things on branch socketio, but did not have time yet to continue the work...

[ls-infra]

looks like we can pass a WebSocket instance if we set `conOptions.$type === 'WebSocketDirect'
https://github.com/TypeFox/monaco-languageclient/blob/main/packages/client/src/wrapper/lcwrapper.ts#L62 ,

for some cases we need to dynamically call the .close for the WebSocket explicitly with the .dispose to free up connection resources .

if we manage the WebSocket instance ourself , and call the WebSocket .close ourself, should we call it before or after the .dispose ?

[kaisalmen]

Hi @ls-infra I just tested this and you should close the WebSocket after you call dispose on the lcwrapper. I have pushed an updated on main where you can configure both options (lcwrapper internal web-socket and external web-socket handling) for a couple of example:
https://github.com/TypeFox/monaco-languageclient/blob/main/packages/examples/src/common/client/extendedClient.ts

[ls-infra]

I think it might be more intuitive to call .close() inside .dispose(). The purpose of .dispose() should be to clean up both client-side and server-side resources when the user stops using the editor (e.g., navigates away from the page).

Is this repo still relevant?
https://github.com/CodinGame/languageserver-mutualized

Or do we now have a scalable solution for handling multiple LSP connections without overwhelming the server with WebSocket connections?

If so, is there an example that demonstrates proper use of multiple LSP connections?

thx

[kaisalmen]

I think it might be more intuitive to call .close() inside .dispose(). The purpose of .dispose() should be to clean up both client-side and server-side resources when the user stops using the editor (e.g., navigates away from the page).

True, I think the whole lcwrapper needs an overhaul (mid-term) and propper tests.

If so, is there an example that demonstrates proper use of multiple LSP connections?

You mean on the server side?

Is this repo still relevant?
https://github.com/CodinGame/languageserver-mutualized

@CGNonofr any thoughts on this?

[CGNonofr]

Is this repo still relevant?
https://github.com/CodinGame/languageserver-mutualized

@CGNonofr any thoughts on this?

Yes, we're using it at CodinGame

[ls-infra]

https://github.com/CodinGame/languageserver-mutualized/blob/main/example/package.json#L8

but it does not seem like it is using the current https://github.com/TypeFox/monaco-languageclient/ ?

can we add a working sample in https://github.com/TypeFox/monaco-languageclient/tree/main/verify ?

[CGNonofr]

I'm not sure how you discover languageserver-mutualized, but it's a server lib, allowing multiple clients to connect to a single language server instance. It has really NOTHING to do with monaco-languageclient

[ls-infra]

there is a use case that need to support multiple monaco-languageclient editors in the same page , and user can switch back and forth and see different code completion.

instead of holding list of new Websocket instances , i try to find a way to just use one Websocket instance to support all monaco-languageclient editors ,
is languageserver-mutualized the way to go ?

because i see here https://github.com/CodinGame/languageserver-mutualized/blob/main/example/package.json#L8 , thus i think languageserver-mutualized uses monaco-languageclient for the front end.

and i ran the example but code completion is not showing up

[CGNonofr]

I'm not sure why you need to run multiple languages client in the same client on the same backend 🤔 You have multiple projects being open at the same time in the client? the lib supports having multiple workspace folder, I see no reasons to run multiple language client in the same page