monaco-languageclient
monaco-languageclient copied to clipboard
feat: add mutualized option to language-server-runner
- [x] I'd be willing to implement this feature (contributing guide)
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 .)
"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?
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)
@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. 🙂
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,
@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?
languageserver-mutualized is open for contributions, if it needs update, that's probably the first step indeed
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
i reckon moving
languageserver-mutualized
into thenpm 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.
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
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
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 ?
@codingame/monaco-languageclient is just a fork that is no longer used
Yes, languageserver-mutualized demo should switch to monaco-languageclient
@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).
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