`--arch` unhelpful on macOS because `get_safe_arch` resets it

[Zegnat]

I was able to make older Node.js builds available for ARM (Apple Silicon / M1) on an internal mirror (provided to fnm with --node-dist-mirror) but it is impossible to get it to download.

I expected the following command to work, but as you can see by the output, it does not:

fnm install --arch arm64 --node-dist-mirror https://example.com/ 12
# Installing Node v12.22.7 (x64)
# error: Can't download the requested binary: v12.22.7 for x64 not found upstream.
# You can `fnm ls-remote` to see available versions or try a different `--arch`.

It took me a while to figure out that fnm was blocking this, especially because the error message kept telling me to try a different --arch. Turns out you are unable to use a different --arch because get_safe_arch will always overwrite my choice:

https://github.com/Schniz/fnm/blob/cc158ea44e9df45f0d9961dd482296e5181eafc1/src/arch.rs#L19-L22

It seemed counter intuitive to me that a manually supplied arch is being overwritten. Surely the worst that can happen is the user providing an arch that Node.js does not offer in their releases and the installation immediately failing? I understand that the arch should default to x64 when someone does a pure fnm install 12, but IMO it should not change the arch if it was manually provided.

Was there any reason for this? Would a PR that does not run get_safe_arch on top of user provided --arch be accepted?

[Schniz]

That's a good question. I think we provide FNM_ARCH with fnm env, so the users pass --arch implicitly with environment variables. Maybe we need to set FNM_FORCE_ARCH? Maybe we need to avoid the special casing and try to download arm64 and fallback to x64 if the file is missing? https://nodejs.org/dist/index.json has files that we don't use right now.

[Schniz]

So anyway I think that the change will not be trivial, but we might want to alter the behavior to look for the files that the node version index provides.

[Zegnat]

I agree that the true answer is probably in the files array. That change is sadly outside of what I feel I could comfortably whip up in Rust.

Would you accept a PR for an FNM_FORCE_ARCH first? If so: would you expect only the environment variable, a --force-arch flag option, or both?

[trm217]

When running fnm install with the --arch flag, the behaviour seems weird all together. I was trying to install Node 14 for arm64 and it just heads straight for installing Node 14 for x64 without any info on that the targeted installation was not available. I think the command should either fail if no installation was found for the defined arch or at least show a information if for some reason an other build is downloaded.

[natew]

Ran into this today, it seems 14 does have arm builds, is there a reason it doesn't allow installing it? The automatic regression to x64 is very unintuitive.

Searching around I guess official support for arm doesn't come until 15, but definitely an error is preferred with maybe a note to link that.

[mshick]

Just encountered this as a fairly new user of fnm. Took me awhile to figure out why --arch was being ignored for v14. Was loving fnm but not being able to install an arm64 node 14 is a blocker.

Big +1 for clarifying this limitation, and perhaps offering a way to force the arch as suggested. Hoping this issue doesn't fall off the radar.

[Schniz]

Ran into this today, it seems 14 does have arm builds

it does not :thinking: i.e. latest version: https://nodejs.org/dist/v14.20.0/ does not have arm builds for darwin, which is what we're talking about here?

Was loving fnm but not being able to install an arm64 node 14 is a blocker

yeah that's annoying too, thankfully our projects migrated to 16 so it's not a real issue. when I need to check stuff on Node 12 for instance, I use node-build but in latest MacOS, given the absence of python@2, we can't really build Node.js from source anymore ☹️

I wanted to use Zig CC to cross-compile all the versions of Node.js and have an alternative repository for Node.js 14 but it didn't work and I have no time to make it work unfortunately. Maybe you can chime in? https://github.com/Schniz/m1-node-versions

[Schniz]

I was very much opposing the idea of compiling versions on the fly because it is extremely slow, so I wanted to add fnm install --compile-if-needed or fnm env --compile-if-needed as a global config. but it does not matter because of the usage of python2 which isn't available on most macos machines anyway 🤷

[Schniz]

I had a thought while driving: what if we had fnm import-installation ./my-self-compiled-node-directory?

[y-nk]

we could also allow trust of 3rd party proposing builds such as https://github.com/a60814billy/node14-apple-silicon-build

EDIT: i've been downloading the 14.17.6 tarball and basically untar in ~/Library/Application Support/fnm/node-versions/v14.17.6/installation. works like a charm.

EDIT2: i didn't see at first but there's a neat env based replacement to make it works seamlessly with nvm. there's definitely something to do there. https://nodejs.raccoon-tw.dev/

[Schniz]

@y-nk good idea. You can already set the node dist mirror but we don’t support index.tab — we can support the tsv file and then it’ll work.