Consider committing transpiled code (the out directory)

[ilkkapoutanen-61n]

Hi,

Since Microsoft recently disabled the vs marketplace feature that allowed downloading .vsix files, installing extensions became more difficult for users in areas with very poor internet, or those working in offline environments. Using another, internet-connected copy of VS Code to download the files is often not an option for these users. Using a GitHub zip download as an installation package is still possible with a directory rename hack: just download the repo as a zip, rename the top level directory to extension, then re-zip it, rename to .vsix and install.

For this to work end to end however, the transpiled form of the extension should exist in the zip file. For these offline users however, having the build-time dependencies or even a build environment can be another significant hurdle. On that note, and to finally get to the point, in order to support this user group, please consider either a) committing the transpiled form of the extension code, or b) submitting .vsix files as artifacts on your releases.

Thanks!

[DavidLGoldberg]

Hi,

I'll give this some more thought/read through.

Sounds like more of a MS problem though. I used to use that download feature too! Primarily, I think, so that I could get vim+jumpy running in Azure Data Studio.

I intentionally don't commit any bin/compiled code (or at least last I checked, definitely don't intend to!).

It all builds on the Azure. And the code for that is open and anyone can see the builds etc. (I think MS/VS Code should actually force/assist that kind of build env for extensions btw, but last I checked you could just upload a zip with basically anything in it).

So basically you're saying...ideally that the releases downloads in gh should include a .vsix ....so if I could generate that AFTER the build and bundle it.... that would be ideal, since allegedly there's no way to grab that file from the vscode marketplace these days?

I actually trigger the builds with a "release" ....I forget when that zip is actually generated but I assume it's frozen to the tag/gh sha that started it all.....

Atom had a cooler way of doing pretty much all of this through the command line apm, leveraging npm I believe.

Are you good with build env's / azure? I'd def consider accepting a PR for this!

Thanks for bringing it to my attention!

[ilkkapoutanen-61n]

Yeah, it totally is a Microsoft problem. Trying to download Jumpy2 was what led me to realise this had changed, and to learn about the workaround of re-packing a GitHub download, and that in turn is why I ended up posting here about it.

You're spot on about the vsix file as a GitHub release download — that'd be just the ticket. The same vsce tool that does the publishing should also be able to package it locally (or in Azure DevOps in this case). The release having been already minted on GitHub at that point is another thing though. Even if the vsix file could be shipped over from AzDO, could it still be added to the release ex post facto? Or would a better solution be to also have a pipeline in GitHub Actions that would package up the vsix and make a release upon seeing a version number tag push?

I'm not comfortable promising anything but I'll try to take a look on my own time, and not burden you with anything overly complicated :)

[DavidLGoldberg]

k, cool, yeah even if it's later on. Better late than never no rush! We'd def have to keep one of the zips, just the clean zip, and maybe another, or bundle some _vsix file or something (yuck)

[DavidLGoldberg]

ex post facto would be great.