Is winget a supported install path for v2, and how does sync's `upgrade` interact with it?

[AllainPL]

winget is still on 1.2.2 - v2 hasn't been submitted yet. The manifests have always come from the community rather than from you, so v2 will land there whenever someone gets round to it.

Two questions off the back of that:

1. Is winget a supported way to install v2, or would you rather people used the installer directly?

2. The source docs say sync.exe handles upgrade. If nvm can upgrade itself, a winget-managed install ends up on a different version than the one winget recorded, and winget upgrade stops lining up. Should self-upgrade be off when nvm came from a package manager?

I use winget for most things, so I'm happy to submit the v2 manifest - unless you're planning to do it yourself. Either way there's one call that's yours: the package is currently CoreyButler.NVMforWindows, and the repo has since moved to the nvm-windows org, so I don't know whether you'd want the identifier to stay as it is.

[coreybutler]

Yes, but as you noted, it's not available yet. I built winget automation into our release pipeline (i.e. official release), but I have to submit this first v2 release manually to prevent the naming conflict you identified.

The sync tool has replaceable dll files. Presently, it will upgrade the binaries in place. This shouldn't have any impact on versions installed via winget since the version is detected from nvm.exe. However; I explicitly made the dll files replaceable so the sync tool can update itself without forcing an nvm update. If an unforeseen problem surfaces with a winget update, we can dynamically fix it without forcing people to reinstall anything.

Important

The dll files are fully COSE 1 signed, even in the community build. The sync tool verifies signatures, refusing to include a dll that isn't explictly signed by our certificates. This way the sync tool cannot be compromised by slipping a rogue dll in.

If winget is your primary upgrade path, then you don't really need nvm upgrade. It shouldn't be a problem if you run it though. The sync tool will provide a notification when new versions are available, so you can upgrade whichever way works best for you. If you happen to run into an issue when that time comes, definitely submit an issue and I'll fix it.

That said, I still recommend the standard installer. There are quite a few configuration options and the wizard walks you through them. It is a generally quick install, does not require admin privileges (though it helps if you want to register the app as a native event source), and has clear screens indicating how migrations from v1 are going.

The Installers doc goes through this. I recommend at least looking at the warnings at the bottom of the page.

I'll keep this open as a placeholder until the winget publish is complete.

[ziyuang]

Same for scoop.

[coreybutler]

@ziyuang Scoop isn't on our roadmap right now. It's something we'll look at if enough people are interested. Open another issue dedicated to scoop because this will get lost once this issue is closed.

[coreybutler]

This may take slightly longer than I originally anticipated. From the looks of it, Microsoft will be pre-installing NVM for Windows in Project Zenith. My initial research suggests it is based on the current winget package. I've reached out to Microsoft to clarify and will attempt to sync up with them on this.

[baywet]

Hi,
It looks like a new version of the winget package was merged recently microsoft/winget-pkgs#437789

From the looks of it, and according to the docs, those are the unsigned bits. So one downside is that people will "downgrade" from signed to unsigned bits if they upgrade without paying close attention.

The other aspect here is that most people would be upgrading from a system install, and most likely doing so under UAC (sudo winget upgrade or so). Which goes against the install recommendation for v2 I'm not sure whether this scenario has been tested for the installer, or whether the winget package needs additional information, but I wanted to flag the potential risk here.

In the meantime, if other readers want to stay behind and not upgrade accidently, you can pin the version on winget with winget pin add --id CoreyButler.NVMforWindows --version 1.*

Note: while I do work for Microsoft, I'm not on the winget or dev tooling product teams, and should be considered as "just another user" in this context.

I hope this helps

[coreybutler]

I have not yet published any of the v2 line to winget. The link @baywet provided was from someone who was impatient and published an incorrect version under my personal ID without authorization. I've filed a removal. I really wish they hadn't done that. I'm trying to get v2.0.1 published today or tomorrow, but this effort causes a naming conflict and we have to wait for a moderator to merge it.

Since this issue was originally filed, I've had a discussion with the Zenith team and several organizations leveraging winget from an OEM perspective. While the core software is ready, the challenge is seamless upgrading from v1. There have been several important edge cases that have been resolved. If you're interested in details, you can see everything that's been added in the 2.0.1 beta release notes. I believe beta.4 has fixed the remaining cases we needed to cover, so now it's just a matter of resolving the winget ID problems.

[3xtant]

I think @coreybutler 's comment explains what I saw today. Glad I checked here. I will wait a few days before upgrading

PS C:\Users\3xtant> winget list --id CoreyButler.NVMforWindows
Name                  Id                        Version Available Source
------------------------------------------------------------------------
NVM for Windows 1.2.2 CoreyButler.NVMforWindows 1.2.2   2.0.0     winget
PS C:\Users\3xtant> winget upgrade --id CoreyButler.NVMforWindows
No applicable upgrade found.
A newer package version is available in a configured source, but it does not apply to your system or requirements.