Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Native support for Apple Silicon (M1 / arm64 architecture) #19908

Closed
thomvaill opened this issue Jan 26, 2022 · 22 comments · Fixed by #20686
Closed

Native support for Apple Silicon (M1 / arm64 architecture) #19908

thomvaill opened this issue Jan 26, 2022 · 22 comments · Fixed by #20686
Assignees
Labels
OS: mac process: build Related to our internal build process type: enhancement Requested enhancement of existing feature

Comments

@thomvaill
Copy link

thomvaill commented Jan 26, 2022

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:

Running cypress on an ARM-based M1 mac is pretty slow under rosetta 2. Considering apple no longer seem to selling new intel macs as of q4 2021, I think it's a pretty important feature to add?

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.json becomes:

{
  [...]
  "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.zip and build/build/Cypress-9.4.0-arm64-mac.zip). And as you can see, the binaries are built against the correct architecture:

# Executed on an Intel macbook
➜  cypress git:(develop) ✗ yarn binary-build --platform darwin --version $(node ./scripts/get-next-version.js)
# [...]

➜  cypress git:(develop) ✗ lipo -archs build/build/mac/Cypress.app/Contents/MacOS/Cypress
x86_64
➜  cypress git:(develop) ✗ lipo -archs build/build/mac-arm64/Cypress.app/Contents/MacOS/Cypress 
arm64

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.json becomes:

{
  [...]
  "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:

  • packaging       platform=darwin arch=universal electron=15.3.4 appOutDir=/var/folders/1v/csfvz7q15w10lvp83zzlp72w0000gp/T/cypress-build/darwin/build/mac-universal
  ⨯ Command failed with a non-zero return code (1):
lipo /private/var/folders/1v/csfvz7q15w10lvp83zzlp72w0000gp/T/electron-universal-YpnsKo/Tmp.app/Contents/Resources/app/node_modules/@cypress/get-windows-proxy/node_modules/registry-js/build/Release/registry.node /private/var/folders/1v/csfvz7q15w10lvp83zzlp72w0000gp/T/cypress-build/darwin/build/mac-universal--arm64/Cypress.app/Contents/Resources/app/node_modules/@cypress/get-windows-proxy/node_modules/registry-js/build/Release/registry.node -create -output /private/var/folders/1v/csfvz7q15w10lvp83zzlp72w0000gp/T/electron-universal-YpnsKo/Tmp.app/Contents/Resources/app/node_modules/@cypress/get-windows-proxy/node_modules/registry-js/build/Release/registry.node

fatal error: /Library/Developer/CommandLineTools/usr/bin/lipo: /private/var/folders/1v/csfvz7q15w10lvp83zzlp72w0000gp/T/electron-universal-YpnsKo/Tmp.app/Contents/Resources/app/node_modules/@cypress/get-windows-proxy/node_modules/registry-js/build/Release/registry.node and /private/var/folders/1v/csfvz7q15w10lvp83zzlp72w0000gp/T/cypress-build/darwin/build/mac-universal--arm64/Cypress.app/Contents/Resources/app/node_modules/@cypress/get-windows-proxy/node_modules/registry-js/build/Release/registry.node have the same architectures (x86_64) and can't be in the same fat output file  failedTask=build stackTrace=Error: Command failed with a non-zero return code (1):
lipo /private/var/folders/1v/csfvz7q15w10lvp83zzlp72w0000gp/T/electron-universal-YpnsKo/Tmp.app/Contents/Resources/app/node_modules/@cypress/get-windows-proxy/node_modules/registry-js/build/Release/registry.node /private/var/folders/1v/csfvz7q15w10lvp83zzlp72w0000gp/T/cypress-build/darwin/build/mac-universal--arm64/Cypress.app/Contents/Resources/app/node_modules/@cypress/get-windows-proxy/node_modules/registry-js/build/Release/registry.node -create -output /private/var/folders/1v/csfvz7q15w10lvp83zzlp72w0000gp/T/electron-universal-YpnsKo/Tmp.app/Contents/Resources/app/node_modules/@cypress/get-windows-proxy/node_modules/registry-js/build/Release/registry.node

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.

@JawaMatter
Copy link

JawaMatter commented Jan 26, 2022

I suppose these are the same issues #18724 #19654 #19908 #4478
I am struggling to run Cypress on new 2021 Mac Pro #19654 (comment)

workaround works https://www.cypress.io/blog/2021/01/20/running-cypress-on-the-apple-m1-silicon-arm-architecture-using-rosetta-2/

#19654 details
System Version: macOS 12.1 (21C52)
Kernel Version: Darwin 21.2.0
Cypress: 9.3.1
nvm 0.39.1
npm 6.14.15
node 12.22.9 (specific for Rosetta 2 and workaround)

@thomvaill
Copy link
Author

thomvaill commented Jan 28, 2022

Yep,

I propose to close #19654, and to continue the discussion here to find a short term solution

@flotwig
Copy link
Contributor

flotwig commented Feb 2, 2022

One blocker to this is testing - how can we test the built .zip with M1 binaries actually works? M1 support in CI blocks this.

@flotwig flotwig added OS: mac process: build Related to our internal build process labels Feb 2, 2022
@thomvaill
Copy link
Author

thomvaill commented Feb 2, 2022

You're right, I missed this point :(

How about:

  • we implement solution 1
  • until there is no ARM support on CircleCI:
    • we test only the Intel binary (like today) and "assume the ARM one should work if the Intel one works"
    • we display this kind of warning when the ARM binary is being downloaded: "The ARM support of Cypress is currently in beta; please follow this tutorial if you are experiencing issues: [link to the workaround]"
  • we enable the test and official support of ARM when supported by CircleCI

?

@Xmaxer
Copy link

Xmaxer commented Feb 4, 2022

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.

@dceddia
Copy link

dceddia commented Feb 15, 2022

I'm running into a related problem, I think. I'm using my own prebuilt universal libraries, but running into the same lipo error shown here.

The registry.node file in cypress is probably either x64 only (which wouldn't work anyway) or it's like mine, where the native library already has both architectures and merging them is failing. You can see which is the case by running otool -L on the files that lipo is using as input. On the library I'm using, otool shows 2 sections, one with "(architecture x86_64)" and the other with "(architecture arm64)".

It seems to me like there are a couple ways to fix this:

  1. Build the native library twice, once for each architecture. Copy each library into the Electron.app with the matching architecture. Then they'll have distinct architectures and lipo can merge them.
  2. Or, build the native library as universal first (build both + merge with lipo), then after the universal Electron.app is packed, copy the universal native library into place (before signing)

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 afterPack step and see if it works.

@nalandial
Copy link
Contributor

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.

@Xmaxer

  1. In Activity Monitor, are all of the browser processes running under Apple, as well as the parent node.js process?
  2. What version of Cypress did you compile?
  3. Which versions of MacOS and node.js did you use to compile & run?

@xeger
Copy link

xeger commented Apr 8, 2022

Just a comment that the workaround (using Rosetta2 + multiple node installs) is an intractable mess.

  • The Cypress launcher frequently crashes with IPC issues
  • Startup time is atrocious
  • The amd64 browser gets slower constantly, and consumes more memory, until I need to restart after 15 minutes

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.

@alectrocute
Copy link

alectrocute commented May 4, 2022

  • packaging       platform=darwin arch=universal electron=15.3.4 appOutDir=/var/folders/1v/csfvz7q15w10lvp83zzlp72w0000gp/T/cypress-build/darwin/build/mac-universal
  ⨯ Command failed with a non-zero return code (1):
lipo /private/var/folders/1v/csfvz7q15w10lvp83zzlp72w0000gp/T/electron-universal-YpnsKo/Tmp.app/Contents/Resources/app/node_modules/@cypress/get-windows-proxy/node_modules/registry-js/build/Release/registry.node /private/var/folders/1v/csfvz7q15w10lvp83zzlp72w0000gp/T/cypress-build/darwin/build/mac-universal--arm64/Cypress.app/Contents/Resources/app/node_modules/@cypress/get-windows-proxy/node_modules/registry-js/build/Release/registry.node -create -output /private/var/folders/1v/csfvz7q15w10lvp83zzlp72w0000gp/T/electron-universal-YpnsKo/Tmp.app/Contents/Resources/app/node_modules/@cypress/get-windows-proxy/node_modules/registry-js/build/Release/registry.node

fatal error: /Library/Developer/CommandLineTools/usr/bin/lipo: /private/var/folders/1v/csfvz7q15w10lvp83zzlp72w0000gp/T/electron-universal-YpnsKo/Tmp.app/Contents/Resources/app/node_modules/@cypress/get-windows-proxy/node_modules/registry-js/build/Release/registry.node and /private/var/folders/1v/csfvz7q15w10lvp83zzlp72w0000gp/T/cypress-build/darwin/build/mac-universal--arm64/Cypress.app/Contents/Resources/app/node_modules/@cypress/get-windows-proxy/node_modules/registry-js/build/Release/registry.node have the same architectures (x86_64) and can't be in the same fat output file  failedTask=build stackTrace=Error: Command failed with a non-zero return code (1):
lipo /private/var/folders/1v/csfvz7q15w10lvp83zzlp72w0000gp/T/electron-universal-YpnsKo/Tmp.app/Contents/Resources/app/node_modules/@cypress/get-windows-proxy/node_modules/registry-js/build/Release/registry.node /private/var/folders/1v/csfvz7q15w10lvp83zzlp72w0000gp/T/cypress-build/darwin/build/mac-universal--arm64/Cypress.app/Contents/Resources/app/node_modules/@cypress/get-windows-proxy/node_modules/registry-js/build/Release/registry.node -create -output /private/var/folders/1v/csfvz7q15w10lvp83zzlp72w0000gp/T/electron-universal-YpnsKo/Tmp.app/Contents/Resources/app/node_modules/@cypress/get-windows-proxy/node_modules/registry-js/build/Release/registry.node

I didn't have time to debug further.

For what it's worth, this should be pretty trivial to fix since it appears to be an unrelated bug. get-windows-proxy needs to be excluded in any macOS-targeted builds, as it's a native node module for working with the Windows registry. I imagine there will be other lipo errors after this fatal error is resolved but electron-builder should handle it... right?

@PeteJStewart
Copy link

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.
I'm using a MacBook Pro with M1 Pro and 16GB RAM.
In generally it seems to be ok when running just one test, although it's a bit slow.

The main issue is if I try to run the whole suite.
It usually run ok the first time, but tends to crash my laptop if I don't switch it off before making any changes.
Also heats up my laptop a lot!

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!

@edikdeisling
Copy link
Contributor

edikdeisling commented May 19, 2022

Been waiting for this feature too. For now, my workaround is(thx for @thomvaill):

  1. Clone Cypress repo
  2. git checkout tags/v9.5.4
  3. yarn
  4. Change electron-builder.json

image

  1. yarn binary-build --platform darwin --version 9.5.4
  2. mkdir -p ~/Library/Caches/Cypress/9.5.4
  3. cp -R build/build/mac-arm64/* ~/Library/Caches/Cypress/9.5.4

After that I have Cypress that works well

@mraible
Copy link

mraible commented May 20, 2022

I tried turning these commands into a script:

#/bin/zsh

VERSION=9.5.4 # set version here

cd /tmp
git clone git@github.com:cypress-io/cypress.git
cd cypress
git checkout tags/v$VERSION
yarn binary-build --platform darwin --version $VERSION
mkdir -p ~/Library/Caches/Cypress/$VERSION
cp -R build/build/mac-arm64 ~/Library/Caches/Cypress/$VERSION

However, it fails at the first yarn command.

HEAD is now at 6fc1bed844 release 9.5.4 [skip ci]
yarn run v1.22.17
$ node ./scripts/binary.js build --platform darwin --version 9.5.4
node:internal/modules/cjs/loader:936
  throw err;
  ^

Error: Cannot find module '@packages/ts/register'
Require stack:
- /private/tmp/cypress/scripts/binary.js
    at Function.Module._resolveFilename (node:internal/modules/cjs/loader:933:15)
    at Function.Module._load (node:internal/modules/cjs/loader:778:27)
    at Module.require (node:internal/modules/cjs/loader:1005:19)
    at require (node:internal/modules/cjs/helpers:102:18)
    at Object.<anonymous> (/private/tmp/cypress/scripts/binary.js:2:1)
    at Module._compile (node:internal/modules/cjs/loader:1105:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1159:10)
    at Module.load (node:internal/modules/cjs/loader:981:32)
    at Function.Module._load (node:internal/modules/cjs/loader:822:12)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:77:12) {
  code: 'MODULE_NOT_FOUND',
  requireStack: [ '/private/tmp/cypress/scripts/binary.js' ]
}

Any ideas how to fix?

@edikdeisling
Copy link
Contributor

@mraible you should install the deps after checkout I suppose...

@mraible
Copy link

mraible commented May 21, 2022

That got me a bit further. Now it seems to fail because of some sort of signing.

afterSign hook triggered in /var/folders/f7/5x4rvsr5599ffnfckn487nzm0000gn/T/cypress-build/darwin/build/mac-arm64
Notarizing com.electron.cypress found at /var/folders/f7/5x4rvsr5599ffnfckn487nzm0000gn/T/cypress-build/darwin/build/mac-arm64/Cypress.app
  ⨯ Missing Apple id for notarization: NOTARIZE_APP_APPLE_ID  failedTask=build stackTrace=Error: Missing Apple id for notarization: NOTARIZE_APP_APPLE_ID
    at module.exports (/private/tmp/cypress/scripts/after-sign-hook.js:32:11)
    at MacPackager.doSignAfterPack (/private/tmp/cypress/node_modules/app-builder-lib/src/platformPackager.ts:330:29)
    at MacPackager.doPack (/private/tmp/cypress/node_modules/app-builder-lib/src/platformPackager.ts:312:7)
    at MacPackager.pack (/private/tmp/cypress/node_modules/app-builder-lib/src/macPackager.ts:177:7)
    at Packager.doBuild (/private/tmp/cypress/node_modules/app-builder-lib/src/packager.ts:441:9)
    at Object.executeFinally (/private/tmp/cypress/node_modules/builder-util/src/promise.ts:12:14)
    at Packager._build (/private/tmp/cypress/node_modules/app-builder-lib/src/packager.ts:376:31)
    at Packager.build (/private/tmp/cypress/node_modules/app-builder-lib/src/packager.ts:337:12)
    at Object.executeFinally (/private/tmp/cypress/node_modules/builder-util/src/promise.ts:12:14)
🔥 deploy error
Error: Command failed with exit code 1: electron-builder --publish=never --c.electronVersion=15.3.5 --c.directories.app=/var/folders/f7/5x4rvsr5599ffnfckn487nzm0000gn/T/cypress-build/darwin/dist --c.directories.output=/var/folders/f7/5x4rvsr5599ffnfckn487nzm0000gn/T/cypress-build/darwin/build --c.icon=/private/tmp/cypress/node_modules/@cypress/icons/dist/icons/cypress.icns --c.asar=false
    at makeError (/private/tmp/cypress/node_modules/execa/lib/error.js:58:11)
    at handlePromise (/private/tmp/cypress/node_modules/execa/index.js:114:26)
    at processTicksAndRejections (node:internal/process/task_queues:96:5) {
  shortMessage: 'Command failed with exit code 1: electron-builder --publish=never --c.electronVersion=15.3.5 --c.directories.app=/var/folders/f7/5x4rvsr5599ffnfckn487nzm0000gn/T/cypress-build/darwin/dist --c.directories.output=/var/folders/f7/5x4rvsr5599ffnfckn487nzm0000gn/T/cypress-build/darwin/build --c.icon=/private/tmp/cypress/node_modules/@cypress/icons/dist/icons/cypress.icns --c.asar=false',
  command: 'electron-builder --publish=never --c.electronVersion=15.3.5 --c.directories.app=/var/folders/f7/5x4rvsr5599ffnfckn487nzm0000gn/T/cypress-build/darwin/dist --c.directories.output=/var/folders/f7/5x4rvsr5599ffnfckn487nzm0000gn/T/cypress-build/darwin/build --c.icon=/private/tmp/cypress/node_modules/@cypress/icons/dist/icons/cypress.icns --c.asar=false',
  exitCode: 1,
  signal: undefined,
  signalDescription: undefined,
  stdout: undefined,
  stderr: undefined,
  failed: true,
  timedOut: false,
  isCanceled: false,
  killed: false
}
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

@mraible
Copy link

mraible commented May 21, 2022

I tried setting my Apple ID and password as environment variables. But then it fails when it tries to upload things.

export NOTARIZE_APP_APPLE_ID=XXX
export NOTARIZE_APP_PASSWORD=YYY
  ⨯ Failed to upload app to Apple's notarization servers

2022-05-21 08:25:05.356 *** Error: Notarization failed for '/var/folders/f7/5x4rvsr5599ffnfckn487nzm0000gn/T/electron-notarize-lFqIXD/Cypress.zip'.
2022-05-21 08:25:05.358 *** Error: Unable to upload your app for notarization. Failed to get authorization for username 'mraible@mac.com' and password. (
    "Error Domain=NSCocoaErrorDomain Code=0 \"Status code: 0\" UserInfo={NSLocalizedDescription=Status code: 0, NSLocalizedFailureReason=The auth server returned a bad status code.}"
) (-1011)
 {
    NSLocalizedDescription = "Unable to upload your app for notarization.";
    NSLocalizedFailureReason = "Failed to get authorization for username 'mraible@mac.com' and password. (\n    \"Error Domain=NSCocoaErrorDomain Code=0 \\\"Status code: 0\\\" UserInfo={NSLocalizedDescription=Status code: 0, NSLocalizedFailureReason=The auth server returned a bad status code.}\"\n)";
}

@mraible
Copy link

mraible commented May 21, 2022

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.

@stokrattt
Copy link

mac m1 pro (os monterey) cypress work very slowly than windows.
When do we get native work cypress without rosseta?

@mjhenkes mjhenkes added the type: enhancement Requested enhancement of existing feature label May 26, 2022
@alavkx
Copy link

alavkx commented Jun 2, 2022

That got me a bit further. Now it seems to fail because of some sort of signing.

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 afterSign config in electron-builder.json.

And just a heads up, my "successful" build ended up throwing an error in the smoke test

smoke test failed with error
code: 'Unknown system error -86',

This is ok! Check build/build/mac-arm64 and you (hopefully) should see that the build still worked and you can finish the remaining instructions.

Thank you @edikdeisling! <3

@killthebuddh4
Copy link

Been waiting for this feature too. For now, my workaround is(thx for @thomvaill):

  1. Clone Cypress repo
  2. git checkout tags/v9.5.4
  3. yarn
  4. Change electron-builder.json
image
  1. yarn binary-build --platform darwin --version 9.5.4
  2. mkdir -p ~/Library/Caches/Cypress/9.5.4
  3. cp -R build/build/mac-arm64/* ~/Library/Caches/Cypress/9.5.4

After that I have Cypress that works well

For what it's worth this worked for me with 10.0.2 as well. Thanks @edikdeisling !!

@cypress-bot cypress-bot bot added stage: needs review The PR code is done & tested, needs review and removed stage: work in progress labels Jun 13, 2022
@hubgit
Copy link

hubgit commented Jun 13, 2022

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.0
git clone https://github.com/cypress-io/cypress.git
cd cypress
git checkout tags/v$VERSION
yarn

Edit electron-builder.json manually as in the screenshot above

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 cypress-bot bot added stage: in progress and removed stage: needs review The PR code is done & tested, needs review labels Jun 14, 2022
@cypress-bot
Copy link
Contributor

cypress-bot bot commented Jun 15, 2022

The code for this is done in cypress-io/cypress#20686, but has yet to be released.
We'll update this issue and reference the changelog when it's released.

@cypress-bot
Copy link
Contributor

cypress-bot bot commented Jun 21, 2022

Released in 10.2.0.

This comment thread has been locked. If you are still experiencing this issue after upgrading to
Cypress v10.2.0, please open a new issue.

@cypress-bot cypress-bot bot locked as resolved and limited conversation to collaborators Jun 21, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
OS: mac process: build Related to our internal build process type: enhancement Requested enhancement of existing feature
Projects
None yet
Development

Successfully merging a pull request may close this issue.