Please support loading WebAssembly modules in extensions

[jmillikin]

I would like to write extensions that use libraries written in languages that compile to native code (e.g. Go, Rust, C). Today the only practical way to do this is to use a separate binary compiled for each platform supported by VS Code, either via LSP or directly invoked subprocesses. This has substantial drawbacks for performance, user experience ("please download a bunch of tools"), and extension update cadence.

Many of these languages also support WebAssembly as an output target, which means in theory I could bundle a .wasm into the extension and run it on any architecture supported by V8. In practice it doesn't work as of VS Code v1.30.1 -- the WebAssembly namespace isn't available to extensions.

Would it be possible to offer the upstream WebAssembly API (or something similar)? Then the extension could look like this:

// extension.ts
export function activate(ctx: vscode.ExtensionContext) {
	const serverPath = context.asAbsolutePath(path.join("server/out/server.js"));
	const implPath = context.asAbsolutePath(path.join("server/out/impl.wasm"));

	let serverOptions: ServerOptions = {
		module: serverPath,
		transport: TransportKind.ipc,
		args: ["--impl-path=" + implPath],
	};
	// ...
}

// server.ts
import * as fs from "fs";
const implBuf = new Uint8Array(fs.readFileSync(implPathFromArgs));
let impl: any;
WebAssembly.instantiate(implBuf, {}).then(result => {
  impl = result.instance;
});
// LSP methods can invoke methods of `impl` to tokenize, search parse tree, etc

References:

• WebAssembly.compile()
• WebAssembly.instantiate()
• WebAssembly.instantiateStreaming()

[jrieken]

The symbols are there but aren't defined in the node.d.ts file. That's why you get a compile error

[bpasero]

Looks like this only came in via nodejs/node#23339, probably needs an update of our dependency to node.d.ts.

[bpasero]

It does not look like WebAssembly appears even with the latest node.d.ts.

[fominok]

Well, I can successfully call my wasm from js vscode extension "thanks" to no compilation. Maybe we can bypass/override these node.d.ts definitions somehow, didn't use ts before
edit:
@bpasero could you tell me where this node.d.ts is located?

[fominok]

@jmillikin here is a workaround I came to today:
For webasm I use Rust language and their wasm-pack tool, which compiles my wasm code and creates npm package. I follow this guide: https://rustwasm.github.io/docs/book/game-of-life/setup.html
So I've created a project from template, let's call it vswasm, and compiled it with wasm-pack build --target nodejs. In generated pkg dir I called npm link.
In freshly created vscode extension directory enter npm link vswasm.
Now in extension.ts I'm able to do imports like import * as vswasm from 'vswasm' and call vswasm.greet().
Second part: memory. To access WA memory we need missing types, so I installed @types/webassembly-js-api with npm into extension folder. Now accessing buffer is simple as

import * as wasm from 'vswasm/vswasm_bg';
wasm.memory.buffer

Didn't do anything more than this now, but it looks like a solution. Hope it helps!

[vscodebot]

This issue is being closed to keep the number of issues in our inbox on a manageable level, we are closing issues that are not going to be addressed in the foreseeable future: We look at the number of votes the issue has received and the number of duplicate issues filed. More details here. If you disagree and feel that this issue is crucial: We are happy to listen and to reconsider.

If you wonder what we are up to, please see our roadmap and issue reporting guidelines.

Thanks for your understanding and happy coding!

[gilescope]

Web assembly isn't on the road map for VSCode extensions in the next 2 years? I find this incredible. I respectfully suggest that maybe this ticket hasn't been given the publicity and due consideration it deserves?

[rusnasonov]

@bpasero can you reopen this issue? Supporting WASM it's a big deal for extension developers.

[fominok]

@bpasero can you reopen this issue? Supporting WASM it's a big deal for extension developers.

hello Emacs my old friend

[bpasero]

I fail to understand how the types for node.js or lib.d.ts do not have WebAssembly in them. @DanielRosenwasser can you shed some light on this? I think the TypeScript team is contributing to the nodejs.d.ts types right? Bottom line: there is a global WebAssembly type in node.js (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/WebAssembly) but it is not typed anywhere in d.ts files it seems?

[orta]

@bpasero - the WebAssembly globals do live in the dom.d.ts based on their spec pages but for them to be available here they would need to be C&P'd into @types/node.

The TS team is generally hands-off on adding new things to any @types/x packages, given the scale of community contributions - we're mainly there to maintain ecosystem stability so I guess it's just been that no-one has sent a PR for it yet

[bpasero]

Ok thanks, if someone is willing to add these types into types/node (https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/node) then we can pull them in. Important: it has to be added to the 12.x branch, as VSCode is not yet on node.js 14.

[jmillikin]

At some point since the original filing of this issue, WebAssembly support has been enabled in the vscode Node environment. While the types are still missing, it is now possible to load a WASM module by adding the following declaration:

declare const WebAssembly: any;

I consider this issue solved, since the WASM API is small enough to operate without full types.

[jmillikin]

If anyone's interested, I wrote up some notes on a "hello world" WASM-enabled vscode LSP server at https://john-millikin.com/extending-vscode-with-webassembly