WASM build of the LSP for VSCode

[kristoff-it]

Instead of telling people to go fetch the Super CLI tool on their own, we could build the LSP sub-command for WASM and have VSCode run it directly.

[kristoff-it]

Related reading from Microsoft: https://code.visualstudio.com/blogs/2024/05/08/wasm

The end of the post mentions a future follow-up dedicated to using wasm in the context of a language server. Based on that it might be too early to work on this, unless one wants to be a pioneer.

[kristoff-it]

Microsoft has released a second blog post on how to do this, which I hadn't initially noticed: https://code.visualstudio.com/blogs/2024/06/07/wasm-part2

I followed the steps in the blog post, discovered that the typescript was mostly broken, then found a commit that fails CI but that fixes the issues with the original code.

After implementing all these changes, ignoring a type error relative to a WebAssembly object, having jacobly help me get past a LLVM error relative to the *| operator, the wasm32-wasi build of the CLI tool succeeded and VSCode was able to init it correctly.

But this is kinda where we stop because after that the language server becomes unresponsive. After some more digging I confirmed that VSCode is sending a handshake request but somehow we never read it all successfully.

To try all of this yourself:

• git switch wasm
• zig build wasm -Ddebug -p editors/vscode/wasm
• Open editors/vscode in VSCode
• Start debugging
• The first time you start debugging, VSCode will complain that it can't install the "wasm core" (display name is "Experimental - WebAssembly Execution Engine") extension because it doesn't have a stable release yet. You need to go into the marketplace and install it yourself manually.

This will start an instance of VSCode with the extension installed. You should see some output in the SuperHTML Language Server channel (it's a drop down availble in the UI area where the terminal is in VSCode).

The main entry point for the WASM build of the language server is src/wasm.zig and currently it has the LSP code commented out in favor of an echo server implementation using LinearFifo.pump. You can uncomment the other lines of code in the main function to turn on the language server code instead.

One interesting fact about the pump behavior is that if you pass a small buffer, it will stop pumping super early (ie it won't even show the full hanshake message which we know for a fact is sent fully by VSCode.

This makes me think that read blocks when it's not expected to.

@Techatrix in case you're interested in taking a look :^)

[kristoff-it]

Reads hang in vscode, somebody somewhere probably forgot to await a promise https://github.com/microsoft/vscode-wasm/issues/178