Add check for Apple Silicon Macs

[Figments]

💡 Feature description

Include support for Apple Silicon Macs, e.g. the late 2020 MacBook Air, late 2020 MacBook Pro 13", and late 2020 Mac mini.

💻 Basic example

Currently, trying to install the wasm-pack library from either NPM or Yarn results in the following error:

Error: Unsupported platform: Darwin arm64

Installing wasm-pack via cargo (using the latest Darwin arm64 support included in Rust 1.49) works flawlessly. It's only the NPM and Yarn version that produces this error.

[anp]

I'm also getting set up on an M1 machine, although I build my wasm-pack from source so didn't run into this. Based on the NPM installer I think the project will also need to upload aarch64-apple-darwin binaries to GitHub Releases.

[anp]

Also FYI once you get it installed there are still some limitations, through no fault of wasm-pack's maintainers AIUI.

[richiksc]

You mention wasm-pack working flawlessly on M1 if installed via cargo or compiled from source. I run into the issue described at #907 when running wasm-pack compiled from source on an M1-based Mac.

[iugo]

➜  curl https://rustwasm.github.io/wasm-pack/installer/init.sh -sSf | sh
wasm-pack-init: no precompiled binaries available for CPU architecture: arm64

[tholu]

@iugo Ran into the same issue, tried cargo install wasm-pack instead and it works so far.

[Xayaan]

Curl command doesn't work on M1, as @tholu stated above. Running cargo install wasm-pack works perfectly.

[huntc]

Having followed the cargo install route, I note that the resultant wasm-pack is built for x86:

huntc@MBP14inch2021 ~ % file `which wasm-pack`
/Users/huntc/.cargo/bin/wasm-pack: Mach-O 64-bit executable x86_64

[fishcharlie]

Is there any plans to fix the curl installer and make the bundle universal or Apple Silicon compatible?

[d3lm]

Yes. This should work on an M1. wasm-opt has a prebuilt for x86-64 and wasm-pack should just download that one for OSX. If rosetta is installed, it will run the x86 automatically without arch. The M1s have been around for a while and we should try and address this issue. Anything I can help with?

I saw it uses the x86 but only if the target is specified as such. But I think for OSX we can just download the x86 always if I am not mistaken. What do ya'all think?

[fishcharlie]

Yes. This should work on an M1. wasm-opt has a prebuilt for x86-64 and wasm-pack should just download that one for OSX. If rosetta is installed, it will run the x86 automatically without arch. The M1s have been around for a while and we should try and address this issue. Anything I can help with?

I saw it uses the x86 but only if the target is specified as such. But I think for OSX we can just download the x86 always if I am not mistaken. What do ya'all think?

@d3lm I think relying on Rosetta is a bad idea. Just like with Rosetta 1, someday Apple will remove support for Rosetta 2. It's best to support Apple Silicon natively for increased performance, and long term stability.

Personally, I'm holding off installing Rosetta for as long as possible. Much more willing to put in the effort in migrating and finding alternatives now, as opposed to later when support is removed.

[d3lm]

@fishcharlie Yes, fair enough. If we can make this work without rosetta that'd be even better. Does that mean we need to build wasm-opt for aarch-64?

[XinyiXiang]

In the installation process of Rust the default settings are as follows:

Current installation options:

   default host triple: aarch64-apple-darwin
     default toolchain: stable (default)
               profile: default
  modify PATH variable: yes

Using cargo seems to be the most reliable way for building on M1s

[d3lm]

@XinyiXiang Using cargo to build wasm-pack or what did you mean?

[Keavon]

I believe this was fixed in 0.10.2 via #1088. If I'm not mistaken, this issue can be closed?

[d3lm]

Yes I think so!

[billti]

I just tried via npm install -g wasm-pack and then via cargo install warm-pack on my new MacBook Pro with M1 chip, and both failed with similar error. The output from the cargo install attempt is below.

I'm seeing a bunch of different arm64 issues on here, some that seem to think this is resolved. But it doesn't appear to be. Any ETA? You need more info?

 ~/src/bqm-wasm/ cargo install wasm-pack
    Updating crates.io index
  Downloaded wasm-pack v0.10.3
  Downloaded 1 crate (423.0 KB) in 0.63s
  Installing wasm-pack v0.10.3
..
<snip>
..
  Installing /Users/billti/.cargo/bin/wasm-pack
   Installed package `wasm-pack v0.10.3` (executable `wasm-pack`)
 ~/src/bqm-wasm/ which wasm-pack
/Users/billti/.cargo/bin/wasm-pack
 ~/src/bqm-wasm/ l ~/.cargo/bin/wasm-pack
-rwxr-xr-x  1 billti  staff   7.4M Nov 13 20:41 /Users/billti/.cargo/bin/wasm-pack
 ~/src/bqm-wasm/ wasm-pack new hello-wasm
[INFO]: ⬇️  Installing cargo-generate...
🐑  Generating a new rustwasm project with name 'hello-wasm'...
Error: Running cargo-generate
Caused by: Bad CPU type in executable (os error 86)

[billti]

Alright. A bit more reading and looks like this depends on Rosetta still - which isn't installed by default on macOS. Running softwareupdate --install-rosetta and then trying again and it worked. It'd be good if this had native ARM64 support and didn't require it, or if the missing prerequisite was mentioned in an error message somehow. Thanks!

[steckes]

+1 took a while to understand what is wrong...

[drager]

Fixed in v0.11.0.

[bbugh]

FYI it appears that 0.11.0 is looking for wasm-opt in the wrong path. A few minutes ago the build was working, I just upgraded wasm-pack, and now there's an error because it's looking for bin/bin/wasm-opt (two bin) instead of just bin/wasm-opt. I would suggest holding off on upgrading if you're on a Mac until this is resolved.

It finds the path correctly first, and then it looks like it fails when trying to execute it.

[INFO]: found wasm-opt at "/opt/homebrew/bin/wasm-opt"
Error: /opt/homebrew/bin/bin/wasm-opt binary does not exist
To disable `wasm-opt`, add `wasm-opt = false` to your package metadata in your `Cargo.toml`.
Caused by: /opt/homebrew/bin/bin/wasm-opt binary does not exist
To disable `wasm-opt`, add `wasm-opt = false` to your package metadata in your `Cargo.toml`.

I was able to work around it by making a symbolic link:

mkdir /opt/homebrew/bin/bin/
ln -s /opt/homebrew/bin/wasm-opt /opt/homebrew/bin/bin/wasm-opt

[mt-inside]

I'm having the above issue on an m1 Mac with newly-upgraded wasm-pack v0.11.0 - it's trying /opt/homebrew/bin/bin/wasm-opt, but

$ which wasm-opt
/opt/homebrew/bin/wasm-opt

[3p3r]

This was indeed not fixed as I encountered the same exact scenario @bbugh describes. On WSL2.

[drager]

@bbugh @mt-inside @3p3r Can you try out latest master?

[bbugh]

master branch appears to be working. I deleted the symbolic link with /bin/bin to be sure.

rm -rf /opt/homebrew/bin/bin/wasm-opt
cd /tmp
git clone https://github.com/rustwasm/wasm-pack
cd wasm-pack
cargo build --release
cd /project-directory
/private/tmp/wasm-pack/target/release/wasm-pack build --target web --release

Success 🌮

[INFO]: ✨   Done in 44.30s
[INFO]: 📦   Your wasm pkg is ready to publish

[mt-inside]

Work on my machine :) Thanks!