For anything under v15, you will need to install node using Rosetta 2.

You can do this by running the nvm installation commands inside the Rosetta 2 shell.

In Terminal, use

arch -x86_64 zsh

to start a shell under Rosetta 2.

Then you can run nvm install v12.

After this, you can use the installed executable without being in Rosetta 2 shell, i.e. you can use node 15 along with other node versions interchangeably.

This way you can use Rosetta on a need to use base and not need to run the whole terminal in Rosetta mode.

FYI @bdruth @olizh

Just fyi - if you set the Open using Rosetta option on Terminal.app or iTerm.app - you’ll save yourself a lot of headache until more stuff works w/ aarch64 and the toolchain on the M1 macs. TBF, most if not all of this stuff already works on, e.g. Raspberry Pi or Amazon Graviton2 instances … but, there’s a lot of bad scripts that hard-code detections for macOS and do something differently … it’ll take awhile to get those sorted, I expect.

Just fyi - if you set the Open using Rosetta option on Terminal.app or iTerm.app - you’ll save yourself a lot of headache until more stuff works w/ aarch64 and the toolchain on the M1 macs. TBF, most if not all of this stuff already works on, e.g. Raspberry Pi or Amazon Graviton2 instances … but, there’s a lot of bad scripts that hard-code detections for macOS and do something differently … it’ll take awhile to get those sorted, I expect.

For anyone wondering how to do this…

1. Right click the app (Terminal, iTerm, etc.)
2. Tap “Get Info”
3. Select “Open using Rosetta”
4. Restart terminal and you’re good to go!

Screenshots

https://github.com/nvm-sh/nvm#macos-troubleshooting

I think they have already a solution…😎

Using Rosetta 2

Check what version you’re running:

$ node --version v14.15.4

Check architecture of the node binary:

$ node -p process.arch arm64

This confirms that the arch is for the M1 chip, which is causing the problems.

So we need to uninstall it.

We can’t uninstall the version we are currently using, so switch to another version:

$ nvm install v12.20.1

Now uninstall the version we want to replace:

$ nvm uninstall v14.15.4

Launch a new zsh process under the 64-bit X86 architecture:

$ arch -x86_64 zsh

Install node using nvm. This should download the precompiled x64 binary:

$ nvm install v14.15.4

Now check that the architecture is correct:

$ node -p process.arch x64

It is now safe to return to the arm64 zsh process:

$ exit

We’re back to a native shell:

$ arch arm64

And the new version is now available to use:

$ nvm use v14.15.4 Now using node v14.15.4 (npm v6.14.10)

🎉

What would be ideal, then, is for nvm to detect that you’re on Apple Silicon, and trying to install a version that’s not supported (< 15, at least), and fail with a helpful message. I’ll leave this open to track that.

Just installed for me on my m1 MacBook Air - nvm version 0.37.0 running nvm i v15

Try upgrading your version of nvm. I just dowloaded via the curl command.

Took a long time though - had to build node from source!

I got a failure to install node v14 via NVM.

I assumed nvm wasn’t working, and attempted installing node v15 via brew (on ARM) and it succeeded.

I’ll try nvm again because I’d like older versions.

–update– Tried nvm again, it’s succeeding for v15, but not node v14.

I guess for now I’ll live without old versions of node 😜

It looks like running nvm install v15 on a Mac M1 CPU does build from source, but it still produces an x64 binary. This can be verified using node -p process.arch -> it prints x64 instead of arm64.

This doesn’t make sense, and is definitely not the case on my machine. Are you sure you’re running the correct, nvm-compiled binary?

$ curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.37.2/install.sh | bash
$ nvm install 15

For anyone wondering how to do this…

1. Right click the app (Terminal, iTerm, etc.)
2. Tap “Get Info”
3. Select “Open using Rosetta”
4. Restart terminal and you’re good to go!

Screenshots

It work well for me

thx ~

tips: need to restart iTerm app

Just fyi - if you set the Open using Rosetta option on Terminal.app or iTerm.app - you’ll save yourself a lot of headache until more stuff works w/ aarch64 and the toolchain on the M1 macs. TBF, most if not all of this stuff already works on, e.g. Raspberry Pi or Amazon Graviton2 instances … but, there’s a lot of bad scripts that hard-code detections for macOS and do something differently … it’ll take awhile to get those sorted, I expect.

Wow! That’s really really helpful! Saved me a lot of time and effort!

Old versions of node might simply not work on apple silicon machines.

Definitely don’t install nvm via homebrew; i don’t support that.

Old versions of node might simply not work on apple silicon machines.

Definitely don’t install nvm via homebrew; i don’t support that.

If you are in a M1 apple silicon machine and want to change to an old node version just follow this link https://dev.to/courier/tips-and-tricks-to-setup-your-apple-m1-for-development-547g

@williamli 's solution worked for me. Thanks!

I’m running an Angular 10 project which requires node 10.13.x/12.11.x. I’m using node 12 via nvm. I came looking for a solution after npm install was running extremely slow. What would normally take my MacBook Pro i7 around a minute, the M1 was was taking more than an hour. Same for ng serve, it was taking forever.

Sorry to rehash what has already been said, but in case it helps anyone this is what I did.

First, confirm the node version and that it’s running on arm64:

~ node -v
v12.11.1
~ node -p process.arch
arm64

Next, uninstall the arm64 version of node. Using nvm, we need to switch to a different version before we can uninstall:

~ nvm use 10
Now using node v10.11.0 (npm v6.4.1)
~ nvm uninstall 12.11.1
Uninstalled node v12.11.1
~ nvm ls
v10.11.0
v15.5.0

Next, switch to x64 and reinstall node 12:

~ arch -x86_64 zsh
~ node -p process.arch
x64
~ nvm install 12.11
Now using node v12.11.1 (npm v6.11.3)

Yeah, existing versions of node 14 simply don’t compile.

I’ve opened a bug here: https://github.com/nodejs/node/issues/36161

Installing older versions of Node wouldn’t work for me either, tried v10 & v12 on the latest version of NVM. Took a long time but v15 installed successfully.

FWIW:

On a new MacBook Air M1 with macOS 11.1 using the default zsh shell, running the curl installation produced an arm64 version of node v15.5.0. 🎉

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.37.2/install.sh | bash

> node -v
v15.5.0

> node

Welcome to Node.js v15.5.0.
Type ".help" for more information.
> process.arch
'arm64'

In zsh, I did:

Downloading and installing node v15.5.0...
Downloading https://nodejs.org/dist/v15.5.0/node-v15.5.0-darwin-arm64.tar.xz...

curl: (22) The requested URL returned error: 404
Binary download from https://nodejs.org/dist/v15.5.0/node-v15.5.0-darwin-arm64.tar.xz failed, trying source.
grep: /Users/suhail/.nvm/.cache/bin/node-v15.5.0-darwin-arm64/node-v15.5.0-darwin-arm64.tar.xz: No such file or directory
Provided file to checksum does not exist.
Binary download failed, trying source.
Detected that you have 8 CPU core(s)
Running with 7 threads to speed up the build
Clang v3.5+ detected! CC or CXX not specified, will use Clang as C/C++ compiler!
Downloading https://nodejs.org/dist/v15.5.0/node-v15.5.0.tar.xz...

I noticed in bash it would download x64

I still got x64 vs arm64 😦

It looks like running nvm install v15 on a Mac M1 CPU does build from source, but it still produces an x64 binary. This can be verified using node -p process.arch -> it prints x64 instead of arm64.

However, building node from source using homebrew creates a correct arm64 build.

I’m not sure if this should be reported as a separate issue. See https://github.com/nodejs/TSC/issues/886#issuecomment-741682896

@williamli it would be great if you PRd a section into the readme for that 😃

@williamli 's solution worked for me. Thanks!

I’m running an Angular 10 project which requires node 10.13.x/12.11.x. I’m using node 12 via nvm. I came looking for a solution after npm install was running extremely slow. What would normally take my MacBook Pro i7 around a minute, the M1 was was taking more than an hour. Same for ng serve, it was taking forever.

Sorry to rehash what has already been said, but in case it helps anyone this is what I did.

First, confirm the node version and that it’s running on arm64:

~ node -v
v12.11.1
~ node -p process.arch
arm64

Next, uninstall the arm64 version of node. Using nvm, we need to switch to a different version before we can uninstall:

~ nvm use 10
Now using node v10.11.0 (npm v6.4.1)
~ nvm uninstall 12.11.1
Uninstalled node v12.11.1
~ nvm ls
v10.11.0
v15.5.0

Next, switch to x64 and reinstall node 12:

~ arch -x86_64 zsh
~ node -p process.arch
x64
~ nvm install 12.11
Now using node v12.11.1 (npm v6.11.3)

Brilliant, thanks @williamli and @sc0tt5!

Those instructions almost worked for me, so I’ve written a gist with the instructions that did work for me, using your comment as a basis: https://gist.github.com/mcalthrop/4618bcaa1b3cd3fe6bba1a9b8bb71b1c I linked back to your GH comment above. 😄

quit the terminal right click - go to “get info” select “open in rosetta” this should allow nvm to install older versions

I just tried this again and it seems that node 15.4.0 is now out, and building it from source using nvm does produce an arm64 binary correctly. I checked python and it seems that it is an universal binary:

$ file `which python`
/usr/bin/python: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64e:Mach-O 64-bit executable arm64e]
/usr/bin/python (for architecture x86_64):	Mach-O 64-bit executable x86_64
/usr/bin/python (for architecture arm64e):	Mach-O 64-bit executable arm64e

Not sure if the new minor version fixed it or maybe I had an incompatible Python which somehow got updated by something I did.

Everything seems good now though.

Thanks guys, when I first installed nvm I took the install script link from an article that I didn’t realise was a bit old and installed v0.33 rather than the latest v0.37. Updating nvm fixed my issue with being able to install the latest version of node, but of course it looks like there is still the issue of installing older versions of node (which is not really the same problem as with my initial issue, but i’m sure I would of run into that one as well).

The support for apple silicon is only on master and possibly 15.x. older versions are expected to not work because they are missing the correct version of V8

solved >>> https://stackoverflow.com/questions/67254339/nvm-install-node-fails-to-install-on-macos-big-sur-m1-chip

I think they have already a solution…😎

Nicely-spotted @sidjoshi001 ! Good looking out, following back to this thread, too! It appears the rumors circulating about you (I’m referring, of course, to those surrounding your pending candidate for the role of “da man”) were well-founded after all. Huh. Well, you got my vote.

For those who got stuck continually building x86_64, make sure your shell itself is the new system defaults. I had previously used the migration assistant and had some left over builds of zsh and bash which were running in rosetta mode in /usr/local/bin.

Before (/usr/local/bin/zsh)

~ λ uname -m
x86_64
~ λ sysctl sysctl.proc_translated
sysctl.proc_translated: 1

After /bin/zsh

~ λ uname -m
arm64
~ λ sysctl sysctl.proc_translated
sysctl.proc_translated: 0

Also make sure that the found python isn’t an x86_64 build either

~ λ file $(which python3)
/usr/bin/python3: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64e:Mach-O 64-bit executable arm64e]
/usr/bin/python3 (for architecture x86_64):	Mach-O 64-bit executable x86_64
/usr/bin/python3 (for architecture arm64e):	Mach-O 64-bit executable arm64e

I guess for those who got an x86 Node while you expect an arm64 Node, please check your Python. If Python is x86 then when Node is doing ./configure, it will generate an x86 Makefile.

i.e. You may need to install Homebrew in arm64 mode, then install Python via that, and make sure your PATH has /opt/homebrew/bin at the front (or uninstall the Python from x86 Homebrew or other previous 3rd-party, non-Apple Python installation)

I think it is time to update the docs on Rosetta now. This has been in for a good while: https://github.com/nvm-sh/nvm/pull/2657

For anyone wondering how to do this…

1. Right click the app (Terminal, iTerm, etc.)
2. Tap “Get Info”
3. Select “Open using Rosetta”
4. Restart terminal and you’re good to go!

Screenshots

It work well for me

thx ~

tips: need to restart iTerm app

In mac M2 chip

Its Terminal instead of iTerm and can be found in the Application/Utilities folder

@imaddi47 what do you think about a PR to automate those steps in nvm itself?

Sure! I would love to.

@imaddi47 what do you think about a PR to automate those steps in nvm itself?

Well, I think just using arch -x86_64 zsh won’t solve our problem. Let us understand this in this way… -> If I am using shell script in which nvm will be used to install a specific version of node at the beginning and then execute further lined up commands. if I am using arch -x86_64 zsh, If will stop the execution of all other commands after arch -x86_64 zsh <~ this one until and unless we tap ctrl + c.

##Usecase Example: 1

We can clearly see here that this approach can’t be used in automation in mac m1 as it will start a new instance of zsh with x86_64 architecture and won’t follow our script to execute next lined up commands… Ultimately our script stuck just after arch x86_64 command

But if modify this as:

It is working fine because we temporarily modified “echo [can be other commands too]” for x86_64

##Usecase Example: 2 Using the same approach for installing node using nvm

Problem if we are not using arch -x86_64 <tools>

Problem if we are using arch -x86_64 <tools>

• Here what we see is nvm is not accessible after adding arch -x86_64 nvm because when we use the inline arch change command, It is unaware of the RC file but it has a path of default locations like echo, bash, zsh, curl, and etc
• So, we have to source RC file every time we install x86_64 based tools

Here is my solution:

Prerequisite:

~> install rosetta 2 using terminal otherwise arch -x86_64 <tool> won’t work

$ /usr/sbin/softwareupdate --install-rosetta --agree-to-license

Solution:

#!/bin/zsh
# Just to get environment path for nvm
source ~/.zshrc

arch -x86_64 zsh -c ". ~/.zshrc && nvm install v12.13.0"
arch -x86_64 zsh -c ". ~/.zshrc && nvm use v12.13.0"
arch -x86_64 zsh -c ". ~/.zshrc && nvm alias default v12.13.0"

Since arch x86_64 <tool> create temporary instance of x86_64 architecture to execute <tool>, we are creating temporary zsh shell with x86_64 architecture to execute desired command. But again, since it is an inline new instance and it is unaware of the RC file. That’s why we are sourcing RC file every time we want to execute third-party tools with their path in RC files.

Code breakdown

• Remember we used #!bin/zsh as our shell, so we intended to perform our operation in zsh with .zshrc file
• we will break our command in different parts 1~> arch -x86_64 2~> zsh -c 3~>". ~/.zshrc && 4~>nvm install v12.13.0"
• arch -x86_64 : initializing new shell instance with x86_64 architecture
• zsh -c : linking that newly created shell with “zsh” and “-c” is for followed up command
• ". ~/.zshrc && : sourcing RC file for “zsh” that is “.zshrc” to load all paths of third-party tools which also included “nvm”
• nvm install v12.13.0" : finally we are running our desired command on x86_64 architecture

That’s all!!! Hope this will help a lot to all of those automation developers who do not intended to use GUI for automating Mac M1

@mcalthrop would you be interested in PRring that content into the readme?

@ljharb Was able to get to it earlier than I expected: #2416

@mcalthrop would you be interested in PRring that content into the readme?

Yes, definitely. I’ll do it as soon as I can – in the next few days.

@williamli it would be great if you PRd a section into the readme for that 😃

@ljharb let me work on it over the weekend.

using the latest version of nvm and i’m having this exact error as well on ubuntu though. Any suggestions on how to resolve it on linux?

Indeed, that will always be the case for compiled deps, but many dep graphs intentionally avoid having those 😃

Quick warning that even once you’ve got the latest nvm up and running, you’re going to be in a world of pain when you try to install dependencies. Pattern of…

node-pre-gyp WARN Tried to download(404): https://fsevents-binaries.s3-us-west-2.amazonaws.com/v1.2.4/fse-v1.2.4-node-v88-darwin-arm64.tar.gz 
node-pre-gyp WARN Pre-built binaries not found for fsevents@1.2.4 and node@15.2.1 (node-v88 ABI, unknown) (falling back to source compile with node-gyp) 

then lots of build errors before it gives up, at least for me.

So even though Node is limited to just building the latest, here’s an OT heads up that lots of other stuff doesn’t appear to be able to do even that. The Bleeding Edge Cuts © 1842.