search

TypeFox / monaco-languageclient

Repo hosts npm packages for monaco-languageclient, vscode-ws-jsonrpc, monaco-editor-wrapper, @typefox/monaco-editor-react and monaco-languageclient-examples
https://www.npmjs.com/package/monaco-languageclient
MIT License
992 stars 171 forks source link

feat: add mutualized option to language-server-runner #595

Open ls-infra opened 5 months ago

ls-infra commented 5 months ago

Description

add mutualized: boolean as new config option to runLanguageServer

Motivation

currently, every time the users open a new tab in the browser, it will create a new language server process (e.g. new java process), which will not be a scalable solution for most cases.

Suggested Implementation

integrate some code from https://github.com/CodinGame/languageserver-mutualized

currently those two interfaces (MessageConnection vs IConnection) are incompatible .

https://github.com/CodinGame/languageserver-mutualized/blob/main/example/src/json-server-launcher.ts#L20 https://github.com/TypeFox/monaco-languageclient/blob/main/packages/examples/src/common/server-commons.ts#L39

( @kaisalmen mentioned "vscode-ws-jsonrpc did not really evolve the last years. It is basically in maintenance mode."

I like to implement this feature if the vscode-ws-jsonrpc is sorted .)

kaisalmen commented 5 months ago

"vscode-ws-jsonrpc did not really evolve the last years. It is basically in maintenance mode."

Yes, I stated that. But, if we see need for improvement, then let's do it. 👍

I'd be willing to implement this feature

Would you also like to work on making the interfaces compatible?

ls-infra commented 5 months ago

yes likely, but may need a bit more context as this may involve multiple packages .

can you please join this https://discord.gg/XzGcpvuh ? or you can send me one if you have any . I find discord easy to communicate in some cases. it is very common in dev community (e.g. https://discord.com/invite/HBherRA , https://discord.com/invite/redwoodjs)

kaisalmen commented 5 months ago

@ls-infra let's keep issue/PR related discussions here, otherwise finding the relevant info is hard for everyone else.

Have you already analysed what the difference of those interfaces are, what you need and how it could be aligned without the lease impact on the overall API? Try altering the lib and aligning an existing example on a new branch. 🙂

ls-infra commented 5 months ago

I understand the importance of using GitHub for detailed discussions. However, I suggest using Discord as an additional tool for productive back-and-forth conversations. Discord's dynamic nature is great for brainstorming and rapid problem-solving, complementing GitHub's structured approach.

We can use Discord for initial, informal chats for brainstorming and then summarise the key points on GitHub Issue for record-keeping and wider community access. This way, we combine the immediacy of Discord with the clarity of GitHub, enhancing our collaboration without compromising transparency.

I believe this dual-channel approach could be very beneficial for our project.

Looking forward to your thoughts.

thx,

kaisalmen commented 5 months ago

@ls-infra a first step should be to update the example in https://github.com/CodinGame/languageserver-mutualized as it still relies on a very old versions of monaco-languageclient and vscode-ws-jsonrpc and then see where things are. Overall it seems to be more efficient to fix that, then to port everything over here and eventually enhance vscode-ws-jsonrpc if required along the way. @CGNonofr WDYT?

CGNonofr commented 5 months ago

languageserver-mutualized is open for contributions, if it needs update, that's probably the first step indeed

ls-infra commented 5 months ago

thx for the comment . i reckon moving languageserver-mutualized into the npm workspace as part of the mono repo will be a better option for easier long term maintenance .

if we need to update something, especially those highly related code , we can just update and release within one mono repo. instead of one package depending on the other's release. this is even more applicable for those are supposed to be used together like vscode-ws-jsonrpc, languageserver-mutualized. For example in this case, once some interfaces are incompatible, we can immediately get noticed and fix it within one release.

i assume most normal users will just use our future languageserver-runner package as a facade which will depend on those two lower levels packages.

with that said, we can still publish those lower levels packages as standalone packages for advanced users who need to use it separately on their own way.

(sorry , the previous link had expired , use https://discord.gg/yXmjuKqm instead if anyone want to join and say hi. even if it is an IM , no one expects anyone reply instantly , i know everyone is busy. so it is just the cases that if i happen to see you guys online , it is just easy to facilitate those kind of back and forth conversation. for the init discussion , we probably can just get it settled within a couple minutes instead of forum like taking weeks to settle an discussion , once the PR is up , i agree that inline comments in PR is more clear)

thanks

CGNonofr commented 5 months ago

i reckon moving languageserver-mutualized into the npm workspace as part of the mono repo will be a better option for easier long term maintenance .

I'm not sure to understand why. The language server types and vscode-languageclient are updated very rarely.

ls-infra commented 5 months ago

it is just a general benefit of a mono repo, not necessary related to the update frequency of related packages.

for example , looks like @codingame/monaco-languageclient (latest 0.17.4) is a direct wrapper of https://github.com/TypeFox/monaco-languageclient according to https://www.npmjs.com/package/@codingame/monaco-languageclient which has the latest version 7.3.0.

if we use mono repo, we probably can reduce the numbers of unnecessary package version release and mismatch. and it reduces the time we need to debug and tracing down dependency chain across different orgs and repos.

Mono repo increases code discoverability of status and changes to help us to achieve smoother release management and easier refactoring.

especially the main contributors for both repos are the same. a mono repo will make more sense according to Conway's law

CGNonofr commented 5 months ago

for example , looks like @codingame/monaco-languageclient (latest 0.17.4) is a direct wrapper of https://github.com/TypeFox/monaco-languageclient according to https://www.npmjs.com/package/@codingame/monaco-languageclient which has the latest version 7.3.0.

I don't follow you here, the languageserver-mutualized demo (labelled as @codingame/monaco-languageclient (latest 0.17.4)) is a wrapper of monaco-languageclient?

if we use mono repo, we probably can reduce the numbers of unnecessary package version release and mismatch. and it reduces the time we need to debug and tracing down dependency chain across different orgs and repos.

Mono repo increases code discoverability of status and changes to help us to achieve smoother release management and easier refactoring.

especially the main contributors for both repos are the same. a mono repo will make more sense according to Conway's law

I'm not really convinced

ls-infra commented 5 months ago

i try to find the github repo for the @codingame/monaco-languageclient, and the https://www.npmjs.com/package/@codingame/monaco-languageclient tells me its github repo is https://github.com/TypeFox/monaco-languageclient . is it a wrapper of the TypeFox one? why we can not just use the TypeFox/monaco-languageclient in the languageserver-mutualized/example/package.json ?

CGNonofr commented 5 months ago

@codingame/monaco-languageclient is just a fork that is no longer used

Yes, languageserver-mutualized demo should switch to monaco-languageclient

kaisalmen commented 5 months ago

@ls-infra the example code id languageserver-mutualized is very similar to the JSON client example here. Compare and adapt the example on branch and open a PR, we can then provide feedback. Start simple, then we can continue from there.

Again, I don't see the need for another communication channel or a need to further restructure this repository apart from what is ongoing (=merging monaco-editor-wrapper).

ls-infra commented 5 months ago

what is the monaco-editor-wrapper package about ? can you simply illustrate what are the dependency chain will be like ?

i assume it will be like :
languageserver-runner(current it is in /example package) -> languageserver-mutualized-> vscode-ws-jsonrpc,

once i finish updating the languageserver-mutualized then you do a release , then languageserver-runner should be able to use it via passing the mutualized config option