Implement platform-specific extensions

[Colengms]

• Update minimum required VS Code version to 1.61
• Replace "*" in package.json with actual events
• Remove "*" activation logic (remove rewrite logic, merge activation and realActivation, remove TemporaryCommandRegistrar)
• Remove code that downloads platform-binaries and checks install.lock
• Remove 'runtime dependencies' from package.json
• Update Offline release pipeline to add --target <platform> when packaging each vsix
• Add manual intervention step after building vsix'es, before invoke vsce publish to publish each vsix
• Remove Online release pipeline

Platform-Specific Extension Documentation

[isidorn]

@Colengms thanks a lot for creating this
Refs: microsoft/vscode#23251

[Tyriar]

Replace "*" in package.json with actual events

Please also avoid using workspace contains if possible, as the extension is far too heavy to activate for projects that contain C++ but may not be the language being worked on.

[bobbrow]

@Tyriar, I'm confused. What other triggers would we activate on then? That is the most important one. Don't all language extensions activate on the presence of their language in the workspace folder? Why else would the facility exist?

[bobbrow]

Nevermind. I should have looked at our activationEvents first. We use:

        "onLanguage:c",
        "onLanguage:cpp",
        "onLanguage:cuda-cpp",

and workspaceContains is only used to look for our configuration file .vscode/c_cpp_properties.json

[Tyriar]

and workspaceContains is only used to look for our configuration file .vscode/c_cpp_properties.json

@bobbrow can that be deferred until a C++ file is opened instead?

[bobbrow]

Can you explain why? If they have this file, then it means the repo is specifically configured for C++ and our extension should load. Python and C# have a similar approach.

[Tyriar]

@bobbrow I suppose an explicit c_cpp_properties.json is fine since it's the file owned by the extension*, as long as it's not checking for *.cpp/h/etc.

An extreme example of where the latter would be damaging is the Chromium codebase which contains C++, Python, C#, JS, PowerShell, ... all these language extensions activating would be obnoxious, forcing the user to either live with a degraded experience (more UI, slower exthost, less available RAM/CPU, slower startup) or micromanage extension enablement. It's enough for the core already to deal with such a large amount of files.

* The extension doesn't create it automatically does it? I had problems in the past with the C++ extension changing files in the workspace without me doing anything.

[bobbrow]

@bobbrow I suppose an explicit c_cpp_properties.json is fine since it's the file owned by the extension*, as long as it's not checking for *.cpp/h/etc.

Yes that file is ours, and we don't do workspaceContains on file extensions.

* The extension doesn't create it automatically does it? I had problems in the past with the C++ extension changing files in the workspace without me doing anything.

We should only be creating or edit that file if someone explicitly invokes one of our C/C++: Edit Configurations commands*. We operate on a default configuration otherwise. If you notice it being added or edited automatically in some other case, that is most likely a bug and we would want to know about it. We received enough feedback in the early days to learn that once that file exists we shouldn't touch it without a really good reason. There are other extensions out there that will try to change our file, but we do not sanction it.

* Actually, the C/C++: Change Configuration Provider can edit the file too if it exists. If it doesn't, it changes a workspace setting instead. But again, this is a user-initiated action, not automatic.

An extreme example of where the latter would be damaging is the Chromium codebase which contains C++, Python, C#, JS, PowerShell, ... all these language extensions activating would be obnoxious, forcing the user to either live with a degraded experience (more UI, slower exthost, less available RAM/CPU, slower startup) or micromanage extension enablement. It's enough for the core already to deal with such a large amount of files.

I'm fairly certain that there is not a c_cpp_properties.json file checked in to the root of the Chromium repo, so if it exists I would have to assume it's because the cloner of the repo wanted it there.

[heartacker]

c# has add this implement, dotnet/vscode-csharp#4775 hope that we can earn it ASAP

[bobbrow]

Our next release (1.8.0) will have it.

[Colengms]

HI @isidorn , I noticed that vsce login doesn't accept a PAT directly. Is there a way to script login such that no user interaction is required (so we can automate that step - publishing 10 VSIX's) ?

[isidorn]

@Colengms great that you are automating this.
I suggest to follow the sample that @joaomoreno created here https://github.com/microsoft/vscode-platform-specific-sample/blob/main/.github/workflows/ci.yml

So yes, you can use the VSCE_PAT env variable. Example how Joao sets it.

[isidorn]

👏 🎉 🚀

[puremourning]

After this change, is there any way to get the vscode-cpptools packages from a known URL ? the vscode marketplace doesn't (to my knowledge) allow direct downloads for offline use

[sean-mcmanus]

@puremourning The marketplace allows direct downloads, e.g. https://marketplace.visualstudio.com/_apis/public/gallery/publishers/ms-vscode/vsextensions/cpptools//vspackage?targetPlatform=linux-x64

[puremourning]

Unfortunately, that's heavily rate-limited and frequency leads to HTTP 429 when this is automated in any way (e.g. in CI, or as part of other DAP client's installation tools):

ben@BenMBP2021 gadget_upgrade % ./download_and_checksum_gadget.py vscode-cpptools
Downloading https://marketplace.visualstudio.com/_apis/public/gallery/publishers/ms-vscode/vsextensions/cpptools/1.9.7/vspackage?targetPlatform=l
inux-x84 to ./cpptools-linux.vsix
Failed - HTTP Error 429: , will retry in 1 seconds

[puremourning]

It seems that the marketplace has a CDN api of some sort, but it seems ... internal... https://github.com/actions/virtual-environments/pull/3244/files / https://github.com/microsoft/vscode/pull/16275/files.

To explain why this matters to me vimspector has an installer which grabs the vsix and uses the debug adapter out of it. It does this for a number of things and while a few of them are using the marketplace, these are not let's say high-volume, but almost all vimspector users install vscode-cpptools and I use it my CI, so it's likely to hit the 429 issue frequently.

[sean-mcmanus]

@puremourning We could potentially go back to our old practice of posting the vsix's on our GitHub Release's page. Do you know if those have the same issue or are you requesting the binaries be available via the fwlinks?

[puremourning]

GitHub releases work great! If you would be willing to add them as artefacts in the GitHub releases that would completely solve my issue!

[sean-mcmanus]

@puremourning Did you want that for pre-releases, which we stopped posting Release pages on GitHub, or the non-pre-release releases (i.e. 1.7.1, 1.8,4, 1.9.7)?

[puremourning]

I only grab release versions, so 1.9.7, etc. for me, there's no need to go earlier than 1.9.7 as I'm going to update to that now but if you can upload them for future 'release' versions that would be great.

[sean-mcmanus]

@puremourning Sure, we can start doing that. The 1.9.7 vsix's have been added: https://github.com/microsoft/vscode-cpptools/releases/tag/v1.9.7

[puremourning]

@sean-mcmanus thank you so much. You're an absolute hero.