Support installation as a Web Extension

[jsejcksn]

It would be very helpful to be able to install and use this extension in browser instances of VS Code (e.g. the Web-based editor on github.dev) as a web extension.

I'm not exactly sure which changes will need to be made to enable this. Initially, I think of the need to support a virtual filesystem, and for Deno's LSP to be available in a worker.

Would Deno need to support wasm as a compilation target? What architectural decisions might make this a challenge? Is it possible for this feature request to align with the project's goals?

[kitsonk]

I think it would be not trivial and complicated. It is worth investigating, but I wouldn't hold your breadth. Also, it likely would need to be a seperate extension. Targetting the whole of Deno CLI for wasm is not practical, but taking things like the module graph already target wasm. deno_lint isn't far away from being available as a wasm library, those coupled with an integration to tsc in the browser would likely be viable.

It would mean it would be seperate from vscode_deno though.

But Deno and the vscode_deno extension are well supported on codespaces, but where you have a dev container to back it up.

[jsejcksn]

Targetting the whole of Deno CLI for wasm is not practical.

@kitsonk Has this been previously discussed in the CLI repo or elsewhere? If so, can you link me so that I can read what's already been covered?

[kitsonk]

Has this been previously discussed in the CLI repo or elsewhere? If so, can you link me so that I can read what's already been covered?

It is self evident, so it hasn't been discussed. Deno CLI is intrinsically tied to Deno core and v8 isolates. Deno core is intrinsically tied to v8. You cannot practically target v8 to WASM to run on v8.

[jrylan]

@kitsonk if deno_lint gets to the point that it's wasm compatible, I can take a shot at submitting a PR to make at least make some aspects of vscode_deno compatible as a web extension. It absolutely can be the same extension, by using the browser field in package.json to serve the web extension version and main to serve the desktop version, that's how VS Code web extensions work. I wouldn't worry about any extra size of the extension bundle for shipping a wasm... I won't name names here, but there are plenty of VS Code extensions that pull down over 100 MB of npm dependencies... Adding an extra 5 to 15 MB for some wasm files is nothing.

Accounting for VS Code settings sync, it should definitely be shipping in the same extension package.

If deno_lint was available via wasm, then to get most of the functionality of vscode_deno working would come down to these points:

1. Bundle the types from deno.ns into the extension and have it include them.
2. The web extension can add a TS LSP plugin the same way to correctly resolve the full relative paths to modules with .ts extensions included.
3. Get the wasm version of deno_lint to hook into the web extension version of the TS LSP.

As far as I know, the code lens feature for running tests is unlikely to work with the web extension version. Would be amazing if that could work though. That's been such a wonderful productivity boost for me.

[beingminimal]

@ry @justjavac @kitsonk @lucacasonato Hey guys if we really want to improve DX as we have mentioned in last para of this blog then we should consider this feature as priority. Because many newcomers, students and low config PC users will be able to develop code for deno without even installing deno locally.

Just imagine guys no need of docker and local installed CLI of deno for development. If stack blitz can achieve for node js then it can be also possible for deno because both uses same v8 engine. Check here. https://blog.stackblitz.com/posts/introducing-webcontainers/

Whole new era of development will be started.

Please discover things in depth if whole things cannot be achieved soon then can we have any solutions from following. Can Deno debugger help to develop https://marketplace.visualstudio.com/items?itemName=ms-vscode.mono-debug

And please check this repo in which they are compiling ts from service worker only. https://github.com/google/playground-elements

Hey everyone please support to achieve this for better DX. Thank you.

[beingminimal]

@kitsonk please let me know how can i be helpful to achieve this?

[LeoDog896]

I think small steps would be nice. Editing deno code on something like vscode.dev is a bit of a hassle as the Deno typings aren't available. Maybe small things like that would be a good start before we get to compiling fmt, lint, and other tools to WASM?