-
Notifications
You must be signed in to change notification settings - Fork 29.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Please support loading WebAssembly modules in extensions #65559
Comments
The symbols are there but aren't defined in the |
Looks like this only came in via nodejs/node#23339, probably needs an update of our dependency to |
It does not look like |
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 |
@jmillikin here is a workaround I came to today:
Didn't do anything more than this now, but it looks like a solution. Hope it helps! |
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! |
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? |
@bpasero can you reopen this issue? Supporting WASM it's a big deal for extension developers. |
hello Emacs my old friend |
I fail to understand how the types for node.js or lib.d.ts do not have |
This comment has been minimized.
This comment has been minimized.
@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 The TS team is generally hands-off on adding new things to any |
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 |
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. |
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 |
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:References:
WebAssembly.compile()
WebAssembly.instantiate()
WebAssembly.instantiateStreaming()
The text was updated successfully, but these errors were encountered: