package: Introduce list-targets flag

[radeksimko]

This is one way of addressing some problems outlined in #625 but more importantly make it easier for end-users to see what targets are even supported without having to look into the source code.

I'm half wondering if this is better implemented as a new subcommand? vsce ls-targets or vsce ls-package-targets, I'm assuming that this would allow easier expansion with more flags later. I imagine that a --json flag might be useful here to change the shell-friendly new-line-separated output to JSON.

[joaomoreno]

Hi @radeksimko, thanks for the PR. I'm not sure a list* option for the package command makes sense. Definitely a separate command would make more sense. But if we with one, I'd just rather go with a full vsce inspect FILE, and that would print all info on the provided VSIX, including which targets it addresses. Feel free to create an issue and PR for this.

Btw, If you'd like to help out, feel free to pick any help wanted issue, those are great candidates for external contributions!

Given this doesn't address at all the need of #625, I'll close it for now.

[radeksimko]

@joaomoreno

But if we with one, I'd just rather go with a full vsce inspect FILE, and that would print all info on the provided VSIX, including which targets it addresses

I'm afraid there is some misunderstanding here.

In my case I'm trying to understand what targets are available before packaging a vsix, I'm not too concerned about inspecting an existing vsix package and neither is #625

The idea was that this command could be used in a script where you just loop over each target and call vsce package --target=$TARGET basically, so be able to generate package for each platform relatively easily.

[radeksimko]

Would you accept vsce ls-targets to tackle this use case?

[joaomoreno]

In my case I'm trying to understand what targets are available before packaging a vsix

This is in our docs: https://code.visualstudio.com/api/working-with-extensions/publishing-extension#platformspecific-extensions

The currently available platforms are: win32-x64, win32-ia32, win32-arm64, linux-x64, linux-arm64, linux-armhf, alpine-x64, alpine-arm64, darwin-x64 and darwin-arm64.

---

The idea was that this command could be used in a script where you just loop over each target and call vsce package --target=$TARGET basically, so be able to generate package for each platform relatively easily.

That completely misses the point of this feature: it's targeted for extensions which actually have different bits per target. #625 exists only for a specific use case: the WSL extension.

What's the actual use case you have for this?

[radeksimko]

We have an extension where the extension (client) code itself is and will remain cross-platform-compatible in the foreseeable future.

However we would like to start bundling the language server with the extension, which itself is not written in Node.js, but in Go and hence the binaries are platform-specific.

I assume there are other extensions which also utilize language servers which are also written in a language that has platform-dependent binaries.

So to clarify the use case - we wouldn't just simply call vsce package --target=$TARGET but also make sure that the right binary is bundled in that package relevant for that target.

[joaomoreno]

So to clarify the use case - we wouldn't just simply call vsce package --target=$TARGET but also make sure that the right binary is bundled in that package relevant for that target.

We suggest to manually list the targeted platforms in your CI, as per our sample: https://github.com/microsoft/vscode-platform-specific-sample/blob/main/.github/workflows/ci.yml