VS Code's appmoniker is "vscode", not "code"?

[Daniel Imms (Tyriar)]

The CLI for VS Code is code/code-insiders and as a result the deb/snap/rpm packages are named code and code-insiders. The winget package should do it as well. I'd like to make this change if it sounds good.

[Daniel Imms (Tyriar)]

cc Kevin Larkin (MS) (@KevinLaMS)

[Nato Boram (NatoBoram)]

I think code is not a good name because it's prone to conflicts. Non-Microsoft projects referencing it are using the moniker vscode. For example, Scoop and Chocolatey.

[Andrew Baker (andrewbaker-uk)]

I have to agree with Nato Boram (@NatoBoram) on this. It's also known as vscode on chocolatey.

[Daniel Imms (Tyriar)]

It's only known as vscode on chocolatey because it's not an official package. If it were it would be consistent with the rest of the packages and the CLI.

[Nato Boram (NatoBoram)]

It's still inherently a bad name for being so prone to conflict. For example, even code on Elementary OS changed their moniker to io.elementary.code. VSCode's repo is also vscode, obliterating your only argument.

[Daniel Imms (Tyriar)]

I don't know if "vscode is used somewhere" obliterates my argument. My argument is to align it with the cli for ux/discoverability reasons:

winget install code
code

apt install code
code

I brought up when I joined the team these potential conflicts with a generic name like code and maybe changing the cli to vscode, but the decision was to keep the cli as code, so packages have inherited that.

[Felipe Santos (felipecrs)]

How about to support 2 monikers?

[Daniel Imms (Tyriar)]

Felipe Santos (@felipecassiors) that's the preference

[Demitrius Nelon (denelon)]

The value "code" makes sense in the "Commands" key, but we've seen more preference for "vscode" as the value for the "AppMoniker" key.

[Daniel Imms (Tyriar)]

Demitrius Nelon (@denelon) the docs say

# List of commands or aliases the user would use to run the package.

Does winget install code work/redirect to it?

[Felipe Santos (felipecrs)]

No, because of multiple matches.

Maybe we should invest in winget install --comand instead, like --moniker?

[Demitrius Nelon (denelon)]

Felipe Santos (@felipecassiors) or Daniel Imms (@Tyriar) if you think that feature would have merit, go ahead and create it in the cli repository. I would expect we might still have a collision between manifests of the released version and the stable version if the meta-data were similar between the two, but the results would be narrowed down.

[Daniel Imms (Tyriar)]

The value "code" makes sense in the "Commands" key, but we've seen more preference for "vscode" as the value for the "AppMoniker" key.

Demitrius Nelon (@denelon) based on this isn't not more of a preference:

Additionally, the preference of the VS Code team is to use code and code-insiders such that winget install code works and it matches the CLI, ideally with both being supported.

It's not clear what the concern about conflicts is, if an app as popular as VS Code comes around and wants to use "code" as well? Searching will still work, just install code should install vscode so it matches the experience on other platforms.

[Felipe Santos (felipecrs)]

But Daniel Imms (@Tyriar), that's not how winget works. In winget world there is not unique and claimable id (different from Chocolatey, Snap, and most of the package managers). The closest thing to it is the Manifest ID, but vscode or code isn't a value that fits in it.

It's not clear what the concern about conflicts is, if an app as popular as VS Code comes around and wants to use "code" as well? Searching will still work, just install code should install vscode so it matches the experience on other platforms.

Monikers are not unique, neither claimable, if two exist, winget will narrow down both, and then you have to choose using the Manifest ID.

The bottom line is there is no way to guarantee winget install code (or vscode) will always install VS Code. But still, vscode moniker can be changed to code.

Or, as I said, what if we ask support for more than one moniker for a manifest? Demitrius Nelon (@denelon) any opinion?

[Felipe Santos (felipecrs)]

I would expect we might still have a collision between manifests of the released version and the stable version if the meta-data were similar between the two, but the results would be narrowed down.

Demitrius Nelon (@denelon) in this case, use -e: winget install --command code -e. The Insiders version of VS Code has a different command: code-insiders.

[Daniel Imms (Tyriar)]

But Daniel Imms (@Tyriar), that's not how winget works. In winget world there is not unique and claimable id (different from Chocolatey, Snap, and most of the package managers).

Ok I didn't know this, thanks.

The bottom line is there is no way to guarantee winget install code (or vscode) will always install VS Code. But still, vscode moniker can be changed to code.

This seems like a real shame. People want to use winget to automate their setup, but there's no way to guarantee that a command will not require manual intervention?

[Demitrius Nelon (denelon)]

Now that the "import" command is available, you can use the "PackageIdentifier" which is unique to a package, and you can build a JSON file with several packages. The Version field can also be used to request a specific version.

[Felipe Santos (felipecrs)]

This seems like a real shame. People want to use winget to automate their setup, but there's no way to guarantee that a command will not require manual intervention?

I meant by using the moniker. But you can do it by using the manifest id:

winget install -e Microsoft.VisualStudioCode

[Daniel Imms (Tyriar)]

Felipe Santos (@felipecassiors) 👍 ok great, this is what I'll recommend using in the docs then. As for the moniker, supporting both code and vscode would be best as you suggested.

[Felipe Santos (felipecrs)]

Felipe Santos (@felipecassiors) 👍 ok great, this is what I'll recommend using in the docs then. As for the moniker, supporting both code and vscode would be best as you suggested.

There is also a feature request accepted, that will prevent you to have to use the -e option:

microsoft/winget-cli#292 - spec

But until there, it is safer to use the -e switch (mainly if the Insiders version of VS Code is also coming).