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
fix: retry on EMFILE always, lint sync FS calls #22175
Conversation
Thanks for taking the time to open a PR!
|
Test summaryRun details
View run in Cypress Dashboard ➡️ Flakiness
This comment has been generated by cypress-bot as a result of this project's GitHub integration settings. You can manage this integration in this project's settings in the Cypress Dashboard |
@@ -563,16 +565,11 @@ describe('_makeSpecWatcher', () => { | |||
|
|||
specWatcher.on('add', (filePath) => allFiles.add(filePath)) | |||
specWatcher.on('change', (filePath) => allFiles.add(filePath)) | |||
specWatcher.on('unlink', (filePath) => allFiles.delete(filePath)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tgriesser I didn't think we'd be seeing this test so soon again :P I had to modify this test to pass after making so much stuff async
, and this line was missing. I think the test is still testing what it's supposed to, can you verify?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One comment/question around extending this to npm
, the rest looks like pretty simple migrations from sync->async. 👏
Also windows is passing on this PR - did you re-run it, or did these changes reduce some flake?
@@ -55,6 +74,16 @@ module.exports = { | |||
message: 'os.userInfo() will throw when there is not an `/etc/passwd` entry for the current user (like when running with --user 12345 in Docker). Do not use it unless you catch any potential errors.', | |||
}, | |||
], | |||
'no-restricted-syntax': [ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wow, hope we don't need to edit this in the near future, did not realize you could do this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah. I pasted a URL there that helps you debug esquery, but even still this took me a bit to figure out.
@@ -38,6 +38,8 @@ export const Cypress = ( | |||
const indexHtmlFile = options.cypressConfig.indexHtmlFile | |||
|
|||
let specsPathsSet = getSpecsPathsSet(specs) | |||
// TODO: use async fs methods here | |||
// eslint-disable-next-line no-restricted-syntax | |||
let loader = fs.readFileSync(INIT_FILEPATH, 'utf8') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this "do not use sync FS calls" also need to be applied in npm, or just things we know are shipping in the binary (and never published separately on npm). It's possible a user is consuming these outside of Cypress (however unlikely) and they may not have access to wrapped fs
module with async extensions.
Seems safest to either us things we know exist in the Node.js standard lib, or have these depend on fs-extra
, or use fs.promises
(didn't know about this!) to making async versions of the functions we need in each npm
module.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd use fs.promises
here if I was gonna change this. I started to, but then stopped because it actually requires a user-facing (I think?) type change to make this function async.
Since this is most likely to run in the plugins process, it should be fine to just use fs.promises
, since we already run gracefulFs.gracefulify(fs)
in the child process:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not too sure this would require a user facing change (this function is internal to the Vite dev server) but sure, happy to leave it like this for now. If we do change it fs.promises
seems good.
I think I just got lucky. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems fine, got an answer on my one question.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changes are thorough 👍 I ran a few smoke tests locally and everything is working good. Also added a few sync calls to test the new eslint rule, that is very cool.
Should we log issues for the few remaining TODOs or will we just keep #22028 open for that work?
@tbiethman I'll update #22028, I think it can encompass the remaining work on this (warn on all sync usage on a monkey-patch level, remove all sync usage) |
* fix: use graceful-fs always, warn in development on sync calls * skip prop linting in some dirs * eslint rules * use AST-based lint rule instead * comment * ignore existsSync * run without nextTick * remove dev warning code * fix order * register TS first * fix tests * fix test * cover new call site * fix new test
cypress open
on Linux #22023User facing changelog
graceful-fs
.Additional details
graceful-fs
tofs
on startup+nextTick to block EMFILE errors - previously, onlyfs-extra
hadgraceful-fs
protectionsAdds warnings for sync FS method usage in the server when not in productionno-restricted-syntax
rule is crazy versatile, you can write arbitrary AST queries to lint usingesquery
syntax.Steps to test
How has the user experience changed?
PR Tasks
cypress-documentation
?type definitions
?