Native support for Apple Silicon (M1 / arm64 architecture) #19908
Comments
|
I suppose these are the same issues #18724 #19654 #19908 #4478 workaround works https://www.cypress.io/blog/2021/01/20/running-cypress-on-the-apple-m1-silicon-arm-architecture-using-rosetta-2/ #19654 details |
|
Yep, I propose to close #19654, and to continue the discussion here to find a short term solution |
|
One blocker to this is testing - how can we test the built |
|
You're right, I missed this point :( How about:
? |
|
I built an ARM64 binary using this method locally, and replaced the binary manually in Cypress. I saw that Cypress was now running directly on M1 from the activity monitor, instead of Intel as it used to before. However, the performance was still equally as sluggish as it was when on Rosetta. People on Intel macs run the test suit very quickly on the other hand. I even verified it was using the new binary as the version changed within Cypress to the version I build the binary in. Did you see any performance improvements when you tested this @thomvaill? It could be of course the OS version we're using that's the issue, but just wondering if there could be more at play here than just building a different binary. |
|
I'm running into a related problem, I think. I'm using my own prebuilt universal libraries, but running into the same The It seems to me like there are a couple ways to fix this:
For Option 1, I was looking for a way to set up architecture-specific files to be copied but I didn't see anything. I'm going to try it out manually with an |
|
|
Just a comment that the workaround (using Rosetta2 + multiple node installs) is an intractable mess.
Please do not let perfect become the enemy of good -- give us a native ARM option even if you cannot test it adequately! Even if the default is AMD64 I need to perform some special step to install the ARM binary, I am happy to do that. The developer experience with Cypress under the status quo is simply not sustainable -- my developers will lose even more confidence in this tool if I force them to deal with crashes, memory leaks and slowness in addition to all of Cypress' flakey test issues. |
For what it's worth, this should be pretty trivial to fix since it appears to be an unrelated bug. |
|
Is there any progress on this, or a timeline for when this might be resolved? Currently I can just about run my tests, but after a little while I tend to run out of memory. The main issue is if I try to run the whole suite. When crashing I receive a message stating that I've run out of memory. An update of when this might be resolved would be great, as it's just about usable at the moment. Many thanks! |
|
Been waiting for this feature too. For now, my workaround is(thx for @thomvaill):
After that I have Cypress that works well |
|
I tried turning these commands into a script: However, it fails at the first Any ideas how to fix? |
|
@mraible you should install the deps after checkout I suppose... |
|
That got me a bit further. Now it seems to fail because of some sort of signing. |
|
I tried setting my Apple ID and password as environment variables. But then it fails when it tries to upload things. |
|
I just tried running Cypress on my M1 and it does appear to be much faster now, so maybe the above process worked. Sorry for the noise everyone. |
|
mac m1 pro (os monterey) cypress work very slowly than windows. |
It seems you've figured it out, but for others reading; If you get this error it's because you've missed the removal of the And just a heads up, my "successful" build ended up throwing an error in the smoke test
This is ok! Check Thank you @edikdeisling! <3 |
For what it's worth this worked for me with 10.0.2 as well. Thanks @edikdeisling !! |
cypress-bot
bot
added
stage: needs review
|
I was able to build an arm64 version using the process described above. I hope to see an official version soon, it runs a million times faster (enough, at least, to make the difference between barely usable and actually quite pleasant to use). VERSION=10.1.0git clone https://github.com/cypress-io/cypress.git
cd cypress
git checkout tags/v$VERSION
yarnEdit yarn binary-build --platform darwin --version $VERSION # the tests will fail, that's fine
mkdir -p ~/Library/Caches/Cypress/$VERSION
cp -R build/build/mac-arm64/Cypress.app ~/Library/Caches/Cypress/$VERSION/ |
cypress-bot
bot
added
stage: in progress
and removed
stage: needs review
|
The code for this is done in cypress-io/cypress#20686, but has yet to be released. |
|
Released in This comment thread has been locked. If you are still experiencing this issue after upgrading to |
What would you like?
The native support of Apple Silicon by distributing an arm64 macos binary, without having to use Rosetta 2 at all.
Solution 1: by distributing two distinct binaries according to the macos architecture (x64 or arm64)
Solution 2: by distributing an Universal macOS Binary
This is not a duplicate of #4478 because I am focusing only on Apple Silicon binaries, not ARM Linux binaries in general.
This is however a duplicate of #18724 which was closed, but since my request and my proposed solutions are a bit different, I prefer to open a new issue.
Why is this needed?
@baversjo wrote a very good summary in #4478:
On top of that, I think the workaround explained here https://cypress.io/blog/2021/01/20/running-cypress-on-the-apple-m1-silicon-arm-architecture-using-rosetta-2/ provides a very poor developer experience, having to maintain two different Nodejs installs with Rosetta.
Proposed solutions
My proposed solution relies on the ability of electron-packager, and thus electron-builder to be able to build macos arm64 binaries on an x64 host, therefore not having to deploy custom CircleCI arm runners, as explained here: electron-userland/electron-builder#5689
Solution 1: two distinct binaries: x64 and arm64
electron-builder.jsonbecomes:{ [...] "mac": { "target": { "target": "zip", "arch": [ "x64", "arm64" ] }, [...] }, [...] }I tested: instead of creating one zip file (
build/build/Cypress-9.4.0-mac.zip), it creates two (build/build/Cypress-9.4.0-mac.zipandbuild/build/Cypress-9.4.0-arm64-mac.zip). And as you can see, the binaries are built against the correct architecture:Then, I suppose we just would have to upload the two zip files, and modify the various mechanisms in place that detect the current arch to download the correct file.
At first sight, the only "tricky" part would be having to patch the arch lib used in
cli/lib/tasks/download.js(because of feross/arch#19)Disclamer: I was not able to test the full build process and thus to test the final binaries on both platforms because I am working on a Macbook behind a corporate proxy, so this is very difficult to install all the correct dev dependencies. Also, I am not a contributor yet so I have a very limited knowledge of the project architecture, so maybe I am missing something.
Solution 2: one universal app
In this case
electron-builder.jsonbecomes:{ [...] "mac": { "target": { "target": "zip", "arch": "universal" }, [...] }, [...] }And electron-builder builds the app twice, for each arch, and should bundle the two binaries into the same app.
Unfortunately, the "merge" phase failed with this error on my side:
I didn't have time to debug further.
Which solution should we choose?
I am not a Mac developer so I don't know what is the best practice here. However, I was not able to test but if I understand well, the merged binary size should double in solution 2. This is why I think solution 1 is preferable in my opinion.
And since all the arch detection/distribution is already in place in the project, it should not be difficult to implement.
The text was updated successfully, but these errors were encountered: