Supporting VS Code for Web

[lostfictions]

I've been using the browser-based version of VS Code a bit lately. It's enormously useful on Github, where you can replace github.com in any URL with github.dev and get a fully-featured in-browser IDE (including forking and making pull requests right from the editor, which I've already put to use amending the docs in repos I don't want to clone and getting better insight into PRs on my own repos).

As it stands, Rewrap isn't available for the Code Web -- it needs to opt in to availability, otherwise it shows up like this:

I took a look at the docs for Code Web Extensions, and from what I can tell Rewrap might already basically be compatible -- since it's already bundling with Parcel, all it might take is to add a browser field pointing at the existing dist/Extension.js to the package.json.

---

EDIT: actually, I see now that CustomLanguage.ts uses fs and path and that in the dist file the other dependencies (json5 and fast-diff) aren't bundled either. I'm not super familiar with Parcel but I assume the latter happens because it detects the Node target via the engines field in package.json and marks any node_modules imports as externals to be left unbundled?

So I guess CustomLanguage might need to be amended a bit for Code for Web support. On the other hand, the npm dependencies look to be browser-compatible and could easily be bundled by Parcel by declaring an additional target.

[stkb]

Thanks for the research; yeah this has been on my radar but I hadn't looked in to it yet.

I believe it's possible to bundle the NPM dependencies with Parcel; it's on my todo list, but I haven't got round to it yet.

The CustomLanguage.ts file is for a feature that searches through the user's installed extensions for language extensions with comment marker info. So that's not going to be possible when running in the browser.

Do you know how an extension can detect if it's running in Web mode? From a quick read through the documentation I haven't found that, though I may have missed it. If that's possible, then it should be easy to disable feature in Web mode and I think the rest should work fine.

[stkb]

Additionally, if microsoft/vscode#2871 / microsoft/vscode#109919 ever gets implemented it will allow that extra feature in the browser too.

[lostfictions]

Do you know how an extension can detect if it's running in Web mode? From a quick read through the documentation I haven't found that, though I may have missed it. If that's possible, then it should be easy to disable feature in Web mode and I think the rest should work fine.

I'm not sure if there's a global or something that's set... But since you can point the browser field in package.json to a different file from the main field, I think the easiest way to handle this might be to have two different Parcel entrypoints that handle informing the extension about what context it's running in.

[stkb]

An update,

But since you can point the browser field in package.json to a different file from the main field, I think the easiest way to handle this might be to have two different Parcel entrypoints that handle informing the extension about what context it's running in.

Yeah this really is what I wanted to avoid though, because of the duplication and added complexity.

For the last release (17.6), I managed to get everything bundled into one file, and added the "browser" field in package.json pointing to that file. I also removed the path dependency, and moved the fs dependency inline with error handling around it.

When testing the extension running on the desktop and in the browser it worked.

However after publishing, when trying to install it from the marketplace: the extension no longer shows the warning triangle; but when you try to install it (the pre-release version), the install still fails. The error message isn't helpful and I can't find any information in the logs either.

It might be (I'm hoping) because I forgot to actually remove the json5 & fast-diff dependencies from package.json (or rather, mark them now as devDependencies). I'll try that for the next pre-release. If that doesn't work I'm gonna be a bit stuck though.

[stkb]

Ok it should now install and work correctly. I tested it briefly. You do have to install the pre-release and not the stable version though.

It will only support built-in languages (the most common) and not those added by extensions, as discussed above; but it might still be possible to add that feature to the web version.

(By digging/stepping though the code during install I found that the actual reason it was failing is because the marketplace still checks the package.json of the stable version, even if you tell it to install the pre-release version. I've now added the "browser" field in the latest stable release, and while that version won't properly support the Web version, it passes the check to allow you to install the pre-release version.)