cli: use includeAllVersions when resolving packs

[vince-fugnitto]

What it does

The commit re-introduces the includeAllVersions flag when querying for extension-packs in order to find a compatible version of a declared plugin. Before the change we were not properly iterating the versions of a plugin which resulted in a plugin failing to download if the latest version was not compatible to our version range (ex: ms-vscode.js-debug).

The change means that we we will properly iterate the versions of a plugin until we hit a version which is compatible with the framework (with respect to our declared supported API range).

How to test

1. confirm that CI for the yarn download:plugins script is successful

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

[msujew]

This fixes the download during the download plugins script, but we also need to adjust the runtime plugin download. See:

theia/packages/vsx-registry/src/node/vsx-extension-resolver.ts

Line 57 in 8831c9d

const { extensions } = await client.query({ extensionId: id });

[paul-marechal]

LGTM, thanks!

[vince-fugnitto]

@msujew thank you for catching it, I managed to fix the following three bugs:

• the resolution of plugins in packs compared to out supported api version
• the download of plugins at runtime
• the ability to open an extension information (vsx-editor) from the extensions-view

[msujew]

Works better, but installing the current German Language Pack from the vsx extension view still fails for some reason. It does work through the Configure Display Language command though, so I'm not sure what's wrong there. Can you confirm Vince?

[vince-fugnitto]

Can you confirm Vince?

@msujew I can confirm as well, the query we use https://open-vsx.org/api/-/query?extensionId=ms-ceintl.vscode-language-pack-de&includeAllVersions=true does not seem to produce any results oddly enough (even when I tried on their swagger ui page.

[msujew]

I can confirm as well, the query we use https://open-vsx.org/api/-/query?extensionId=ms-ceintl.vscode-language-pack-de&includeAllVersions=true does not seem to produce any results oddly enough

I see. In that case we're not really responsible for the issue, as it appears to be a regression from open-vsx. The main issue that this change covers is fixed anyway, so I'll approve as well.

[vince-fugnitto]

@msujew actually, it might just be the fact the open-vsx is case-sensitive:

• https://open-vsx.org/api/-/query?extensionId=MS-CEINTL.vscode-language-pack-de&includeAllVersions=true

The following would produce results.

[msujew]

@vince-fugnitto Oh well, that seems to be new... Any chance you can quickly get the case sensitivity issue fixed in this PR as well?

[vince-fugnitto]

@msujew it seems like supporting case-sensitive values for parameters will cause changes in a lot of areas for plugins, namely for how we scan and read them and also determine a plugin is installed, and how we rely on the toLowerCase(). I did ask the question to open-vsx if the changes are intended (eclipse/openvsx#768) (afaik the restriction was not present before). I'll keep investigating what might be necessary to get everything to work.

[msujew]

@vince-fugnitto Sounds good. Though it makes sense to merge this fix now to get it into today's release.