publish to openvsx

[rohan-sircar]

Please consider publishing the vscode extension to open-vsx.org

The latest version of VSCodium has switched to using openvsx as the extensions provider. (VSCodium is a project which seeks to provide a 100% open source version of VSCode).

You can read more about openvsx here.

[bjorn3]

1. Register on open-vsx.org through GitHub OAuth.
2. Create an access token and copy it.
3. Run npx ovsx create-namespace --pat with the publisher name specified in the extension’s package.json.
4. Run npx ovsx publish --pat in the directory of the extension you want to publish.

The publish itself shouldn't be too hard to setup. However I don't know if EclipseFdn/publish-extensions#41 ([matklad.rust-analyzer] error TS2307: Cannot find module 'vscode' or its corresponding type declarations.) is a problem with rust-analyzer or the specific setup at open-vsx/publish-extensions.

[matklad]

We don't have bandwidth to publish to more than one marketplace. People are encouraged to re-publish from Microsoft's store to open-vsx though.

[Mazwak]

I'm not sure I understand.

The extension is updated more or less once a week, and weigts 200 KB.

Maybe I'm missing something, but that's negligible bandwidth.

[matklad]

Sorry for being unclear, I've meant "maintenance bandwidth" -- publishing requires non-trivial amount of maintenance work from developers.

[jankeromnes]

publishing requires non-trivial amount of maintenance work from developers.

I don't think this cost is very high: Publishing to OpenVSX uses the same tech as publishing to Microsoft marketplace (i.e. both use vsce).

So, you could imagine adding one extra line to your existing Microsoft publishing script, and that line is:

npx ovsx publish

That's it. (It also requires a OVSX_PAT token that you can get from here, but otherwise there is no additional maintenance cost.)

[matklad]

The biggest cost here is maintaining a separate trusted identity (token) for a openvsx store. Some additional smaller costs are:

• having one more failure point during release process (if open vsx is down, release process breaks)
• having one more npm external dependency (ovsx) which needs to be versioned, updated, etc.

More generally, anything that touches build and/or release process, in my experience, is a big cost, even if the actual diff is small.

[jankeromnes]

Good points, thanks for explaining them.

The biggest cost here is maintaining a separate trusted identity (token) for a openvsx store.

This still doesn't seem significant to me (i.e. visit https://open-vsx.org/user-settings/tokens once, generate a token, save it in GitHub Secrets, done). But maybe you're considering things like regular secret rotations?

• having one more failure point during release process (if open vsx is down, release process breaks)

True, but since OpenVSX publishing would be considered non-critical, npx ovsx publish errors could simply be ignored (e.g. with something like npx ovsx publish || true).

• having one more npm external dependency (ovsx) which needs to be versioned, updated, etc.

npx just fetches the latest release of a NPM package (here ovsx) to run it on-the-fly, so there is no need to add a dependency (other than npx, which comes built-in to npm) or to care about its version.

[est31]

FYI it's being republished now as a daily job, but that means that updates are reaching users delayed by up to a day.