Add support for Windows on ARM

[soapdog]

My Environment

• Windows 10

This is just an enhancement request. I've noticed that NVM4W distinguishes between 32 and 64 bits but not between ia32, amd64 and arm64. If using NVM4W on a Windows on ARM machine. An arm64 machine will be identified as 64 bits but it can't run x64 executables, it can run x86 though. So it would be good to have a clause on install.cmd to handle it.

[coreybutler]

I'd be interested in learning more about the environments people would use this in. My biggest concern is capacity. Node/npm are both pretty big (relatively speaking). Multiple installations can eat up alot of hard disk capacity... perhaps too much. NVM4W itself is small, but I'd never really considered mobile or device environments. It makes sense to support it, but I'd like to have a frame of reference for this.

[soapdog]

@coreybutler I'm talking mostly from the point of view of developers using machines like Surface Pro X which is a full windows 10 machine able to run windows arm native binaries and emulated ia32 binaries for windows.

At the moment the native arm64 win32 version of NodeJS is not ready for prime time but it is good enough to start testing. The problem is that switching between the arm64 version and the ia32 version is a manual job at the moment. Most package managers (chocolatey, scoop) and tools like NVM4W are not yet ready for Windows having a new architecture. The Surface Pro X identifies itself as a 64bits machine and lots of apps simply assume that means x64 which don't actually work on those machines.

I totally understand if you don't have capacity or will to take this into account since it is very early for those architectures but I felt like leaving an enhancement request here if only for it to be revisited some time from now when there are more machines and support for Windows on ARM out there.

[coreybutler]

Thanks for detailing that @soapdog. I'd forgotten about Surface Pro X... good use case.

Personally, I feel like any version manager should be able to support switching to a different architecture. After all, the point is to be able to switch to different versions for testing, upgrading, etc... I think this aligns with that goal.

My bandwidth is restricted by other projects (one of which is NVM4W's successor), but I'd be open to a PR. For anyone who reads this and is inclined to contribute, my biggest concern would be error handling and messaging. If the user's system doesn's support the architecture, that's ok.... as long as an error clearly explains why NVM4W can't continue. Retrospectively looking at NVM4W, I wish there were more detail in the errors. Lots of people get npm errors or other system errors that have nothing to do with NVM4W, but it's hard to tell due to generic error messages. For an entire architecture, it would be important to make it very clear that the machine/OS itself does or doesn't support it.

[elanpang]

Qualcomm released the snapdragon X elite with great performance, the arm64 version supporting will be necessary I think.

[nixxcz]

I'm using nvm on ARM64 version of Windows 11 in Parallels Virtual Machine on MacBook Pro with Apple Sillicon M1.

Since an ARM64 build of NodeJS for Windows exists, I would love if nvm was able to install and manage it.

[alexaka1]

Even if one downloads and copies the arm64 build manually, nvm lists it as available locally, but nvm use says it is not installed.

[fluiddot]

Microsoft seems to be betting a bit more on ARM machines which might make this issue more relevant than when it was originally created.

https://www.theverge.com/2024/5/20/24160498/microsoft-arm-surface-laptop-6-qualcomm-snapdragon-x-elite

[alexaka1]

In the meantime fnm supports ARM on Windows (too). You can use --arch <ARCH> to set the architecture for new installs. That solved my needs.

[talynone]

There's a PR for it, but no one has pushed it forward, I'm guessing a dev with write access and an ARM computer is not available.

#1070

[coreybutler]

I'm the only dev (always have been). I don't have an ARM device to test on, but Go cross-compiles. The reason for the delayed merge is our code signing certificate is locked (because I was trying to add an automated release process that failed too many times).