Skip to content
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

Web VS Code extensions cannot activate ms-vscode.wasm-wasi-core #210

Open
jacbz opened this issue Oct 29, 2024 · 10 comments
Open

Web VS Code extensions cannot activate ms-vscode.wasm-wasi-core #210

jacbz opened this issue Oct 29, 2024 · 10 comments
Labels
bug Issue identified by VS Code Team member as probable bug
Milestone

Comments

@jacbz
Copy link

jacbz commented Oct 29, 2024

When writing a web-only VS Code extension, i.e. with a package.json that only defines a "browser" entrypoint, the extension will not activate when depending on ms-vscode.wasm-wasi-core:

"extensionDependencies": [
    "ms-vscode.wasm-wasi-core"
]

Minimal working example:

  • Install the WASI based WebAssembly Execution Engine from the Marketplace.
  • Download the official lsp-web-extension-sample example.
  • Add ms-vscode.wasm-wasi-core as an extension dependency and run.
  • The extension will not activate and will display the error:
    Cannot activate the 'lsp-web-extension-sample' extension because it depends on the 'WASI based WebAssembly Execution Engine' extension, which is not loaded. Would you like to reload the window to load the extension?
    
    Reloading the window does not fix the issue.

Tested on Mac (with the default "Run Web Extension" launch option; VS Code 1.94.0, on Sonoma 14.6.1), and also within a self-hosted web environment.

@CareyJWilliams
Copy link

FWIW I've recently noticed this behaviour as well but hadn't quite got to the point of investigation where I felt comfortable raising an issue just yet (as opposed to believing it was user error on my part).

The only thing I can add to the above is that I can get a node based extension using WASM and WASI Core working, but anything browser (extensionDevelopmentKind=web) based does seem to exhibit the above.

@jacbz
Copy link
Author

jacbz commented Oct 30, 2024

Me too! I've been building a Rust language server compiled to WebAssembly. It works fine in Node, but on the Web, the client seems to have trouble communicating with the server (sendRequest does not reach the server). Weirdly enough, the server can communicate with the client just fine. I'm wondering if these issues are related.

@dbaeumer
Copy link
Member

I never tried to run it in the web extension host on the desktop app. I always test the web stuff inside a browser. Can you load the extension into the browser. An example that does this is here: https://github.com/microsoft/vscode-extension-samples folder wasm-language-server

@dbaeumer dbaeumer added the info-needed Issue requires more information from poster label Oct 31, 2024
@jacbz
Copy link
Author

jacbz commented Oct 31, 2024

The issue also occurs in a browser – I'm running an instance of openvscode-server

@CareyJWilliams
Copy link

I never tried to run it in the web extension host on the desktop app. I always test the web stuff inside a browser. Can you load the extension into the browser. An example that does this is here: https://github.com/microsoft/vscode-extension-samples folder wasm-language-server

I can sideload things, like this sample, into vscode.dev just fine - the WASI dep is automatically installed and the extension works just fine. It's just the web extension host on the desktop app that's proving problematic for me, which I appreciate probably isn't the primary use case - but it's a shame that it doesn't work.

@dbaeumer
Copy link
Member

dbaeumer commented Nov 1, 2024

I will have a look to see why this is failing. One reason might be the following:

  • since the wasm-wasi-core extension has a main entry it will very likely be loaded as a desktop extension
  • when the lsp extension is loaded as a web extension it will fail since dependencies need to be in the same extension host.

@dbaeumer
Copy link
Member

dbaeumer commented Nov 1, 2024

@jrieken do we have a way to force an extension into the web extension host on the desktop?

@jrieken
Copy link
Member

jrieken commented Nov 1, 2024

Yeah, only having the browser entry point in package.json should force you into the desktop web EH. Wild, qualified guessing that you might wanna restart VS Code with --enable-coi because on desktop cross original isolation is not enabled by default

@CareyJWilliams
Copy link

Thank you @dbaeumer , @jrieken. I've managed to get somewhere with the above steps combined.

First, I downloaded a copy of wasm-core and modified its package.json to remove the "main" entry point. Installing that modified version got me past the dependency error but I then also needed to run VS Code with --enable-coi for message passing to start functioning properly. I haven't played around in great depth, but it looks like everything works "as it should" at that point. It's a shame it's not a little easier to do this, but I'm delighted to know it can be done.

@jacbz
Copy link
Author

jacbz commented Nov 4, 2024

Thank you @dbaeumer , @jrieken. I've managed to get somewhere with the above steps combined.

First, I downloaded a copy of wasm-core and modified its package.json to remove the "main" entry point. Installing that modified version got me past the dependency error but I then also needed to run VS Code with --enable-coi for message passing to start functioning properly. I haven't played around in great depth, but it looks like everything works "as it should" at that point. It's a shame it's not a little easier to do this, but I'm delighted to know it can be done.

That works! However, I'm unable to enable COI with Visual Studio Code Server because --enable-coi is not an option there. ?vscode-coi does not work either – anyone have a workaround?

@dbaeumer dbaeumer added bug Issue identified by VS Code Team member as probable bug and removed info-needed Issue requires more information from poster labels Dec 18, 2024
@dbaeumer dbaeumer added this to the On Deck milestone Dec 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Issue identified by VS Code Team member as probable bug
Projects
None yet
Development

No branches or pull requests

4 participants