Nvm installs by Building Source on M1 MacbookAir but installs directly when installing from M1 Pro on a MBP - Both on latest macOS Ventura 13.3.1

[matheustavaresdev]

Hi,

I have a Macbook Air M1 and a MacbookPro M1 Pro, and on the M1 Pro, I've always been able to install the node versions quickly. Yesterday I made a total cleanup on my Macbook Air with the regular M1, and it was taking forever to install node v18.

Today when back to my Macbook Pro M1 Pro, I tried to install v16 and v18.1 and it installed directly from the binary:

nvm install 18.1
Downloading and installing node v18.1.0...
Downloading <https://nodejs.org/dist/v18.1.0/node-v18.1.0-darwin-arm64.tar.xz>...
############################################################################################################# 100.0%
Computing checksum with sha256sum
Checksums matched!
Now using node v18.1.0 (npm v9.6.4)

I did set up nvm on both macs myself and did the same steps for both.

Would there be any reason or anything that would make the M1 Pro install every node version directly from the binary and not the regular M1? Or is there any config that I did on the M1 Pro and forget about that makes it always download from a binary?

I also saw that there's a -b flag to skip source install, but it's really weird that this seems default on M1 Pro and not on regular M1...

Also, on the m1Pro I've installed NVM using the script, but on the regular m1 I've installed via brew but then uninstalled and installed via script, and the error kept coming. Nvm v0.39.3 was used on these tests.

Any lights on this? :(

[ljharb]

It all depends on which binaries node itself makes available. If there's one available for your M1, it would install it directly, but since it's not, that implies that there isn't one.

[matheustavaresdev]

After testing on a friend's same M1 Air, could confirm the issue was only on my machine.

I have YADR ( https://github.com/skwp/dotfiles ) installed on my friend's M1 air and on both of mine M1 Air and M1 Pro, and I really have no idea why only on my air it had those issues.

But then, I also realized that I was getting this error when trying to install on my machine: awk: non-terminated string and after reading this #2921 (comment) I tried running nvm with bash instead of zsh and it installed correctly from binary.

So I tried removing all of my aliases and it worked.

Found the culprit: After commenting this line https://github.com/skwp/dotfiles/blob/master/zsh/zsh-aliases.zsh#L7 it worked again! Which is weird because another similar alias is still active: https://github.com/skwp/dotfiles/blob/master/zsh/aliases.zsh#L137

Seems the issue is really regarding changing capital L into less. Not really sure what's the real difference as I've never used this command before... But at least it's fixed now! Hope this is useful to someone!

Created this issue on YADR as well for visibility and awareness skwp/dotfiles#885.

Thanks for the help and quick response any way @ljharb !!

[ljharb]

ah, that’s an issue that the latest version of nvm should fix. What version is installed on those machines?

[matheustavaresdev]

Actually, 0.39.3 on m1 air and 0.39.1 on M1 pro

[matheustavaresdev]

Also, when installing nvm, it tells me to add to my zshrc a different set of instructions than the git does:

NVM Install script:

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.3/install.sh | bash                               
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 15916  100 15916    0     0  46195      0 --:--:-- --:--:-- --:--:-- 46674
=> nvm is already installed in /Users/ext.mtavares/.nvm, trying to update using git
=> => Compressing and cleaning up git repository

=> nvm source string already in /Users/ext.mtavares/.zshrc
=> bash_completion source string already in /Users/ext.mtavares/.zshrc
=> Close and reopen your terminal to start using nvm or run the following to use it now:

export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"  # This loads nvm
[ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion"  # This loads nvm bash_completion

Git instructions:

export NVM_DIR="$([ -z "${XDG_CONFIG_HOME-}" ] && printf %s "${HOME}/.nvm" || printf %s "${XDG_CONFIG_HOME}/nvm")"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh" # This loads nvm

Not really sure if there's a difference...

[ljharb]

weird, I’d expect the pro then to be the one with the problem.

There’s no difference there unless you care about XDG and the location of nvm itself.

[matheustavaresdev]

Just updated my M1 Pro to use 0.39.3 and started to have the same issue as M1 air... Building from source unless I remove that alias! :(

[ljharb]

Ah, ok, then the next version will fix the specific L issue - otherwise it’s an unavoidable issue with zsh global aliases, which violate posix.

[matheustavaresdev]

So in the end, it was not an issue with the chip itself (regular M1 / M1 Pro), but with nvm version...

[ljharb]

Closing as fixed by #3012.

[matheustavaresdev]

Ah, ok, then the next version will fix the specific L issue - otherwise it’s an unavoidable issue with zsh global aliases, which violate posix.

Gotcha! Yea, I'm also glad that I was able to fix... My m1 air was stopped for an year and a half ish, and before it would also always install from source... So, maybe that issue was also present in an older version of nvm, but I've made a clean install on it when I created this issue so I cant really tell which version it was using... But it's great to know it's not an issue with my mac and that we could find out the "root cause" of it! :D