Lann Martin (Jun 05 2025 at 14:07): Lann Martin (Jun 05 2025 at 14:07):To expand a bit: wasi (used by wasm32-wasip2) and the component model (used by wit-bindgen) are technically different things.
Lann Martin (Jun 05 2025 at 14:09):It isn't surprising that they get conflated: they are being developed in parallel and releases between the two tend to happen more-or-less simultaneously.
Notification Bot (Jun 05 2025 at 14:19):MareStare has marked this topic as resolved.
Lann Martin (Jun 05 2025 at 14:19):Actually you might be able to target wasm32-wasip2 without actually importing wasi interfaces if you build with no_std, but I don't recall for sure if that works.
MareStare (Jun 05 2025 at 14:20):Yeah, I thought about no_std, although I do need alloc in this case
Lann Martin (Jun 05 2025 at 14:22):You can still use alloc but you have to reference it through the separate top-level alloc crate (which can make dependencies painful)
Lann Martin (Jun 05 2025 at 14:27):It might still be easier to target wasm32-unknown-unknown and figure out either cargo component or wasm-tools component new which convert a component-model-flavored wasm module into a wasm component
matt rice (Jun 07 2025 at 07:29):I'm quite curious about the WASI-Virt approach, this is the first I've heard of it, IIUC the native vscode uses wasi, while running in the browser IIUC they have some kind of a VFS. So naturally I'm curious if it is possible to make the wasi-virt filesystem component use whatever vscode in the browser is using? (I don't expect I'll have any time in the near future to experiment with vscode in the browser, just curious)
MareStare (Jun 07 2025 at 17:28):use whatever vscode in the browser is using
I haven't dug too deep into this, but I don't think VSCode in browser provides any FS interface. There is no terminal even. This is what I know from reading the webassembly post from VSCode that was published in 2023. There they demonstrated a workable web shell that uses a virtual FS. The source code of that web shell is public on github
MareStare (Jun 07 2025 at 17:30):@Victor Adossi I ended up using cargo component build --target wasm32-unknown-unknown, thanks! Although a strange thing is that cargo component seems to still require wasm32-wasip1 with this command. Basically I need both wasm32-unknown-unknown and wasm32-wasip1 targets installed. Is this expected?
Milan (rajsite) (Jun 07 2025 at 22:01):I think so, in Victor's post they mention panic machinery ends up pulling wasi in as a dep
matt rice (Jun 08 2025 at 10:48):MareStare said:
I haven't dug too deep into this, but I don't think VSCode in browser provides any FS interface.
It has been quite a while since I've looked into it, I believe where I saw this was in this language server extension example, (sorry if this is too many links)
main.rs
This appears to be built using wasm-wasip1 here:
package.json
Yet the whole thing is deployable to the web in a browser,
running-the-sample-on-the-web
Then in here they note:
The opened workspace or folder is on a virtual file system. Access to workspace files needs to go through the VS Code file system API accessible at
vscode.workspace.fs.
testing on vscode.dev
That is primarily refering to js extensions, e.g. not using nodejs APIs to access the fs directly, but going through the vscode API which can then emulate a filesystem in memory.
So the only thing I imagined is they are also doing something similar to wasi-virt but for wasip1, assuming I'm understanding their build process, and they are deploying wasip1 builds in the browser?
matt rice (Jun 08 2025 at 10:50):So, is this just a case of wasip1 runs in browsers reliably but wasip2 doesn't (yet)?
MareStare (Jun 08 2025 at 12:55):That does seem weird, but I think it worked because that VSCode guy wrote some packages like these https://github.com/microsoft/vscode-extension-samples/blob/cf30922221d1c2dcb819da857b7f64583991fed0/wasm-language-server/client/src/extension.ts#L9 under the @vscode/*wasi* umbrella that implement the wasi interfaces in terms of VSCode API. VSCode does have FS-like API that allows reading files of the extension like here
matt rice (Jun 10 2025 at 15:06):@MareStare
One last thing to note about this (and more relevant to your original question), in the vscode-wasm repo (Ths is the repo with that wasm-wasi-lsp library you linked to),
there are two wasm-wasi-core is the thing that runs wasm32-wasip1 on both the desktop and the web,
In that same repo there is a directory: wasm-wasi-core-preview2 I'm not sure how one goes about using it, and the design.md file in common/ seems to indicate that there are still some problems that need solving.
Ralph (Jun 17 2025 at 09:46):hey, if you have any questions about vscode implementations, @Dirk Bäumer is around and can answer -- though he's currently not working on that at the moment. (He's in CET)
Dirk Bäumer (Jun 17 2025 at 19:53):The preview2 implementation is work in progress and is not functional right now.
Last updated: Dec 06 2025 at 05:03 UTC