cypress: Change in test file crashes component tests after upgrading to Mac
Current behavior
Hello! Thanks in advance for your assistance with this issue.
After I updated to Mac Ventura, I started seeing that any change to my test file crashes my open component tests as can be seen in the attached video. Changes to the non-test code does not crash the component tests.
https://user-images.githubusercontent.com/6589960/197911652-6fccf5b8-7ade-410a-a2c2-c6c78ff59bea.mov
[Stack trace](http://localhost:50705/__/#)
Error: EPERM: operation not permitted, utime '/Users/willweiss/Library/Caches/Cypress/10.11.0/Cypress.app/Contents/Resources/app/packages/server/node_modules/@cypress/webpack-dev-server/dist/browser.js'
at utimesSync (node:fs:2025:3)
at EventEmitter.CypressCTWebpackPlugin.onSpecsChange (/Users/willweiss/Library/Caches/Cypress/10.11.0/Cypress.app/Contents/Resources/app/packages/server/node_modules/@cypress/webpack-dev-server/dist/CypressCTWebpackPlugin.js:64:13)
at EventEmitter.emit (node:events:513:28)
at EventEmitter.emit (node:domain:489:12)
at EventEmitter. (/Users/willweiss/Library/Caches/Cypress/10.11.0/Cypress.app/Contents/Resources/app/packages/server/lib/plugins/child/dev-server.js:9:21)
at EventEmitter.emit (node:events:513:28)
at EventEmitter.emit (node:domain:489:12)
at process. (/Users/willweiss/Library/Caches/Cypress/10.11.0/Cypress.app/Contents/Resources/app/packages/server/lib/plugins/util.js:33:26)
at process.emit (node:events:513:28)
at process.emit (node:domain:489:12)
at process.emit.sharedData.processEmitHook.installedValue [as emit] (/Users/willweiss/Library/Caches/Cypress/10.11.0/Cypress.app/Contents/Resources/app/node_modules/@cspotcode/source-map-support/source-map-support.js:745:40)
at emit (node:internal/child_process:939:14)
at processTicksAndRejections (node:internal/process/task_queues:84:21)
SpecRunner
Passed:
4
Failed:
--
Pending:
--
[EnsureFeatureSwitchesFetched.cyC.test.tsx](http://localhost:50705/__/#)344ms
EnsureFeatureSwitchesFetched
blocks rendering children until feature switches are fetched from the API when switch is onpassed
blocks rendering children until feature switches are fetched from the API when switch is offpassed
uses feature switches fetched from NativeApp if available and doesn't call the API if all necessary switches are presentpassed
still makes a request to the API if the NativeApp doesn't have all the feature switches we needpassed
ChromeChrome 106
360x760 (92%)
Desired behavior
In this situation, cypress should stay open after updating my test file
Test code to reproduce
Tests are run via
TZ=America/New_York yarn cypress run --component --browser chrome --config watchForFileChanges=false
on version 10.11.0.
with a cypress.config.ts file that looks like this
export default defineConfig({
projectId: ...,
downloadsFolder: "src/test/cypress/downloads",
fixturesFolder: "src/test/cypress/fixtures",
screenshotsFolder: "src/test/cypress/screenshots",
videosFolder: "src/test/cypress/videos",
defaultCommandTimeout: 10000,
watchForFileChanges: false,
viewportWidth: 360,
viewportHeight: 760,
retries: {
runMode: 2,
openMode: 0
},
video: false,
chromeWebSecurity: false,
e2e: {
baseUrl: "https://parent-android-web.classdojo.test:4002",
setupNodeEvents(on, config) {
on("file:preprocessor", cypressEsbuildPreprocessor({}));
return config
},
specPattern: "src//**/*.cyI.test.{ts,tsx}",
supportFile: "src/test/cypress/support/e2e.ts",
},
component: {
setupNodeEvents(on, config) { },
specPattern: "src/**/*.cyC.test.{ts,tsx}",
supportFile: "src/test/cypress/support/component.js",
devServer: {
framework: "next",
bundler: "webpack",
},
},
});
### Cypress Version
10.11.0
### Node version
v16.17.0
### Operating System
macOS
### Debug Logs
_No response_
### Other
_No response_About this issue
- Original URL
- State: closed
- Created 2 years ago
- Reactions: 7
- Comments: 39 (20 by maintainers)
@TapaiBalazs Thank you for providing a reproducible example. After further investigation it seems as though this is a permissions issue. As @lmiller1990 explained, when you create a new spec file,
uTimesSyncupdates the timestamp forbrowser.jsfile thereby ‘tricking’ webpack to re-bundle - in the process adding the newly created spec file to the new bundledbrowser.jsfile.The issue on my MacOS Ventura is that
Visual Studio Codedid not have full disk access. You can change this by going to:system settings - privacy and security - full disk accessand toggling on access for visual studio code. I believe this gives Visual Studio access to write to files thereby allowing Cypress (while it is running on VSC) to update the timestamps forbrowser.jsthroughuTimesSyncThis is definitely not a permanent solution but is merely an explanation and a work around without having to manually comment out the code in your bundled files.
Let me know if this solution works for you.
I think we’ve got a fix, please wait a few days, @astone123 will post a PR.
This fix is in Cypress 12.7 - let us know if you are still having issues.
Not sure if it helps but I was able to finally solve this (absurdly annoying) issue by adding my Terminal and IDE (IntelliJ) to the “App Managemet” Setting which will enable these apps to update or delete other apps.
I added both apps because this is where I start my tests from.
Just to mention, I got this error almost every time I change code. Now it’s working for hours since 👻
MacBook Pro 16", 2021 Ventura 13.2.1 (22D68)
<kbd>Settings</kbd> > <kbd>Privacy & Security</kbd> > <kbd>App Management</kbd> (Section Privacy)
Yeah I think that what happens here is that the application that open the Cypress application needs to have the right to update or delete other applications because there is something inside the Cypress application files that need to be changed or looked at when component tests are running.
If the thing that is changing or is checked against would live outside of the
Cypress.appdirectory, then this issue might not happen.@marktnoonan That is exactly what I did yesterday after my Terminal asked me for that very permisson – right after I started the cypress test runner.
But now I’m afraid to revoke this permssions just for verifying this issue because everything runs smoothly now 🙈
Anyhow, I just did that and fiddled around a bit and I can confirm that the issue is back after revoking those permissions. After regranting, the issue is gone again. So it’s reproducible now I guess.
@TapaiBalazs I agree with you that giving full disk access to an IDE is definitely not a permanent solution and is merely a workaround. Cypress needs access to folders and files in this path
/Users/btapai/Library/Caches/Cypress/10.11.0/Cypress.app/Contents/Resources/app/packages/server/node_modules/@cypress/webpack-dev-server/dist/in order to read and write to the Cypress files in cache. Providing full disk access allows Cypress to do this. Ideally Cypress would have access to all its downloaded binaries irrespective of the IDE being used.We will definitely be looking into a more permanent solution but I’m glad we have a work around for now.
I had the same problem with Cypress 10.10.0 I updated to 12.7.0 and the problem is gone for me, thank you very much, good job 😃
That would explain why I didn’t have these issues recently, thanks for the report @gearsdigital - I recently got a new computer with Ventura. Somewhere in the flow of setting up I agreed these permissions, I just checked, and it’s exactly as you said, terminal + IDE.
I did a similar thing as @gearsdigital did. For me, it was the terminal that I had to add to the list of applications that can update or delete other applications:
Now the error went away.
My mac specs:
For anyone else who comes across this, the only way that I could get this to go away is by editing the permissions for
/Users/<user>/Library/Caches/Cypress/<version>/Cypress.app/Contents/Resources/app/packages/server/node_modules/@cypress/webpack-dev-server/dist/browser.jsvia Finder. This is the file that we edit when the spec changes in order to force Webpack to re-compile.It doesn’t seem to matter what exactly I change, but in my case what I did was
Like Lachlan said, you’ll now see the permissions in terminal as
-rw-r--r--@, the@being some attributes that are Mac specific that must have been added when we were editing permissions via Finder. It seems like those attributes are what is allowing us to now write tobrowser.jsand not throw the error, because the file permissions are exactly the same otherwise.This is only a workaround until we can find a way to either stop editing this file or fix the permissions issue with the way that we package the application. Not sure why this is only happening on Ventura
@amehta265
Yes I understand, thank you very much for everything! 😃
@amehta265 I use Webstorm, but I can confirm that when I added it to the full disk access list in the settings, the issue is not present anymore.
Although, I do wonder how good of an idea it is to give full disk access to an IDE. 🤔
@lmiller1990 Thank you for your input! Based on that I was able to create a reproduction:
See the video: https://user-images.githubusercontent.com/13385210/199425420-1725de39-ba00-4c3d-8f4a-95adcd73e1c3.mov
Which I also uploaded to this reproduction repository: https://github.com/TapaiBalazs/cypress_24398_repro
Please let me know if I can help you further
So, in my opinion, there are two issues at play here:
utimesSyncmight no longer be a viable option. 🤔When I run the command with sudo, the same issue happens, that’s why I think the issue has something to do with the new MacOS version.
I wonder if you launch Cypress with sudo does it make a difference? Obviously not a real solution, but it would be one way to verify it’s definitely a permissions issue.
We need
utimeSyncto force webpack to re-compile when a new spec file is added or removed. By commenting this out, you would need to restart Cypress every time you add a new spec (when using webpack dev server).If someone who can reproduce this wanted to explore some other API to touch the browser.js file, that would be a good way to debug. I suspect the problem will happen regardless of how you touch that file, though, since it’s a permissions issue (from what I can see).
In the meantime, I wonder if we should just add a
try/catchto that part of the code, so at least Cypress won’t crash. This might be a good enough fix until we can properly isolate the problem, WDYT @amehta265?