Provide a VS Code web extension entrypoint

[TiemenSch]

Since the VS Code extension already uses WASM compilation of the Rust language server, I believe it should be possible to add a browser entrypoint to the extension. That would mean that users could use it on https://vscode.dev or similar web-based environments.

Their migration instructions are listed here: https://code.visualstudio.com/api/extension-guides/web-extensions#migrate-extension-with-code

[TiemenSch]

I'm currently trying this out with a custom language server I'm building with a similar setup and think I'm well underway to figuring it out. Will report back today or tomorrow!

[TiemenSch]

So I have a proof-of-concept working in my own extension's repo. I'm by no means an esbuild/bundling/extension expert, so I would love to hear any good suggestions/improvements on that front. It works for both the node and browser entrypoint. Some caveats, though:

• the Worker of each client (webworker) doesn't seem to be cleaned up properly if workspace folders change and clients are stopped and restarted in the browser. This can result in duplication of errors. I had to change the path handling to use VS Code's internal Uri type. This gets rid of the dependencies on the path:node and friends, but might be the culprit. Or the worker should be cached somewhere and properly .terminate()d on client stop.
• the WASM is encoded inline in both the JS output files for the servers because I don't know how to bundle it as a single static file properly. For small language servers I think this shouldn't be much of a problem, but it's not quite as elegant as having the plain WASM file in your ./out tree.

Any constructive suggestions are highly appreciated :) https://gitlab.com/ratio-case-os/rust/esl-compiler/-/tree/main/vsx

[wiiznokes]

Sorry for asking this here, but do you know why their server doesn't use another process instead of js binding?

[TiemenSch]

There are many different ways to run a language server and connect to it with a client such as VS Code, but this issue goes about rather making it "more JS like" such that it also works fluently in the browser version of VS Code. (like https://vscode.dev). On such web targets, spinning up a process isn't the same thing as on a local desktop environment.

With VS Code being an electron application, it makes sense to keep things in JS land for both desktop and web.

I'm exploring the route of compiling to Rust code to a WASM file and using that on every platform with preferably minimal JS code to glue things together. When properly setup, that should keep the setup simpler.