VSX: Add 'Install Another Version...' Command

[seantan22]

What it does

• Supports the ability to install any compatible version of an user-installed extension, provided that the extension is available in the Open VSX Registry.

install_another_version.mp4

How to test

1. Open the extensions view and locate the Installed view of all user-installed extensions.
2. Pick an extension --> Click the manage gear icon --> Click Install Another Version... command. Note that the command is disabled for any extension not available in the Open VSX Registry.
3. Select a compatible version to install from the Quick Pick dropdown.
4. Observe that the previous version is uninstalled and replaced with the newly selected version.

Review checklist

• as an author, I have thoroughly tested my changes and carefully followed the review guidelines

Reminder for reviewers

• as a reviewer, I agree to behave in accordance with the review guidelines

Signed-off-by: seantan22 [email protected]

[msujew]

I've updated the coding guidelines regarding i18n. I'm currently working on tooling to simplify finding localization keys in vscode language packs.

[vince-fugnitto]

The changes overall look good to me, only had a minor comment about the quick-input.

[vince-fugnitto]

For some reason I do not see current added as a description to the current extension version:

current-version-ext.mp4

I also verified when it is not the first entry in the list. (not sure why I mentioned this)

[colin-grant-work]

@vince-fugnitto, thanks for pointing out the (Current) issue. It got knocked out by some changes from Rob Moran's tooltip commit. You mentioned that the current version wasn't first - I don't think it should be, necessarily. Here's a screenshot from VSCode.

Earlier, you also expressed some misgivings about the mid-stream undeployment and redeployment. It seems as though VSCode pretty much always prompts you to reload if you want to change plugin versions. Should we just do the same, adding a button to reload if the plugin is awaiting deployment? In Electron that's fairly straightforward - I'm not quite sure what we should do in the Browser, since it would be expecting a full shutdown and restart of the back end.

[vince-fugnitto]

You mentioned that the current version wasn't first - I don't think it should be, necessarily.

That's right, not sure why I mentioned it should be the first in the list, I believe I just wanted to express it should be added to the currently deployed version 👍

Earlier, you also expressed some misgivings about the mid-stream undeployment and redeployment. It seems as though VSCode pretty much always prompts you to reload if you want to change plugin versions. Should we just do the same, adding a button to reload if the plugin is awaiting deployment? In Electron that's fairly straightforward - I'm not quite sure what we should do in the Browser, since it would be expecting a full shutdown and restart of the back end.

I'm not sure either. Are there cases where a plugin will not be updated until the app is reloaded?

[colin-grant-work]

@tsmaeder, would you be willing to weigh in here, since y'all at Red Hat probably have the best understanding of the plugin system. Is it / should it be safe to uninstall one version of a plugin and start a different version in the same session, or would it be preferable to restart the whole application when swapping out versions of plugins?

[tsmaeder]

@colin-grant-work I have two observations:

1. I didn't see any code that adds a plugin to a running plugin host process, so we'll have to at least restart the plugin host, which is usually done by reloading the browser window.
2. Adding a plugin should not be a problem (we do it in "plugin dev mode"), but removing one may leave code running in existing plugin hosts that relies on resources that might not be there anymore. Think of an icon that has been removed in a newer version of the plugin. So I think replacing a plugin requires the back end to be restarted, because we don't have a separate set of deployed plugins per plugin host.

[paul-marechal]

So I think replacing a plugin requires the back end to be restarted, because we don't have a separate set of deployed plugins per plugin host.

@tsmaeder Unless the backend stores plugin-specific data, I don't see why we would need to restart it. An extension's executable code is loaded into the plugin host process only and resources such as icons should be loaded in the frontend, so I'd expect to only need to restart frontend and plugin host?

[colin-grant-work]

Planning to pick this back up, but ran into an issue with the queries to Open VSX. I'll try to work around it - I'm not sure we need the query that's failing.

[colin-grant-work]

@JonasHelming, this one has been waiting on a solution for issues with plugin uninstallation: #11084. Once that's merged, I can finish this up straightforwardly.