Leverage WASI Preview2

[eduardomourar]

I believe a lot could be simplified by leveraging the WASI preview2 + WIT work that is happening here. From the JavaScript binding generation perspective, you might have a look in this repo too: https://github.com/bytecodealliance/jco.

[dbaeumer]

@eduardomourar thanks for pinging me about this. I started to look into this today (I first wanted to to get our support finished for preview1) and I have a couple of questions. I hope you don't mind if I ask them.

May some background first: also we implement a WASI host in JavaScript things are special for us since we want to wire them up to VS Code's extension host API. So we can't simply take a Node.js or Browser implementation (see here for some more details: https://code.visualstudio.com/blogs/2023/06/05/vscode-wasm-wasi). For preview1 I converted the corresponding witx files per hand to d.ts files simply to better understand how everything works. For preview2 I want to convert them automatically since it would allow me to generate more code to hook things up to the VS Code API. So my concrete questions are:

• do you know of a tool that takes a wit file and generates a d.ts file. I looked into https://github.com/bytecodealliance/jco and I somehow got the impression that the d.ts files are generated from wasm/wat files. I would like to keep all the comments and add them to the d.ts as well. In additional I would like to generate additional code to match VS Code's API.
• do you know of any compiler tooling (e.g. C/C++, Rust) that already support preview2 as a target

[eduardomourar]

• The JCO tool does what you are describing. It actually generates bindings for a JavaScript-compatible host (both js and d.ts files) from a WIT definition. You can find an example of usage here. As far as I remember, it does keep the comments in its output.
• There is no support for the WASI preview2 in the languages yet. Meanwhile you can use this adapter to load a preview2 module in a environment that supports preview1.

[dbaeumer]

I started looking at jco and what I need to do for VS Code. Since things will be special in VS Code (it is not a pure browser nor a pure Node.js environment) I am currently exploring the following approach:

• implement the canonical API (https://github.com/WebAssembly/component-model/blob/main/design/mvp/CanonicalABI.md) in a way that matches VS Code characteristics. Especially we need to support forwarding API implementation from the wasm worker thread to the extension host main thread.
• Generate VS Code implementation from a wit file.

A first implementation cut is in branch dbaeumer/monetary-ox-cyan. Interesting might be:

• vscode-wasm/wasm-wasi-core/src/common/preview2/wasi.ts

  Line 1 in b33d132

  /*---------------------------------------------------------------------------------------------

• and a WIT parser and AST based on Peggy (

  vscode-wasm/tools/src/wit.pegjs

  Line 1 in b33d132

  {{

  )

Please note that this is all work in progress however I think that parts of the canonical API implementation might be useful for projects that use TypeScript. It is very likely not useful for project that use pure JavaScript since I use some TS typing rules to make the usage side easier (see for example how Variants are handle using is statement)

vscode-wasm/wasm-wasi-core/src/common/preview2/wasi.ts

Line 1203 in b33d132

export class TestVariant implements JVariantCase {

and

vscode-wasm/wasm-wasi-core/src/common/preview2/wasi.ts

Line 1216 in b33d132

red(): this is { value: u8 } {

[dbaeumer]

I cleaned up the implementation and add the last two types (list and char). Is in the branch in head.