VScode.dev plugin

[adamziel]

The VS Code extension doesn't work on vscode.dev:

The documentation explains:

Extensions that are running code need to be updated to support running in the browser sandbox. You can read more about what is involved to support extensions in the browser in the web extension authors guide.

The guide lists a number of restrictions. We are affected by at least those:

The VS Code API can be loaded via the pattern require('vscode').

That's an easy fix – just add require('vscode') where it's missing.

Node.js globals and libraries such as process, os, setImmediate, path, util, url are not available at runtime. They can, however, be added with tools like webpack. The webpack configuration section explains how this is done.

wp-now and other packages in this repo use node modules extensively and would have to be refactored. Not sure how involved would that be yet. Technically, there could be a @wp-playground/runtime module or so that would expose runtime-specific versions of these libraries.

• 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.

The extension calls worker = new Worker(__dirname + '/worker.js');. I'm not sure if that's okay.

For accessing web resources, the Fetch API must be used. Accessed resources need to support Cross-Origin Resource Sharing (CORS)

Once wp-now supports Blueprints, it will use fetch(). I'm worried about the CORS part, though. I don't see any blockers for WordPress.org to support it for the downloads we need (WordPress core, plugins, themes), but it may take some time and attention from the systems team.

cc @sejas @danielbachhuber @dmsnell @wojtekn

[adamziel]

Actually, there already exists a version of WordPress Playground that fulfills all those criteria. It's the web version.

An isomorphic version of wp-now would be really useful here for features like mode detection and wp-cli support. Or two packages like wp-now/web and wp-now/node, much like we do with php-wasm. But a single isomorphic package sounds much better and easier to maintain.

This is also relevant for the browser extension:

WordPress/wordpress-playground#316

[adamziel]

Playground CLI relies mostly on isomorphic APIs these days, perhaps it would be easy enough to adapt for VSCode.dev.

[sejas]

Agreed, Playground CLI would be easier to use on vscode.dev . I wonder if wp-now should also use Playground CLI.

[bgrgicak]

I wonder if wp-now should also use Playground CLI.

That would be great!