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
chore: minor tidy up of code #603
Conversation
cdc1f24
to
d7881f1
Compare
import rule, { | ||
JestVersion, | ||
_clearCachedJestVersion, | ||
} from '../no-deprecated-functions'; | ||
|
||
const root = process.cwd(); | ||
afterEach(() => process.chdir(root)); |
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.
process.chdir
is not actually supported by Jest. It works since it's the real chdir
, but it breaks a bunch of Jest's assumptions. Since it actually changes dir, it leaks between test files and the jest process itself.
It's not new though, so no need to change now. But something to keep in mind 🙂
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, which is what's happening here - turns out the tests I wrote for the rule are what's been causing the weird CI failure.
I'm not sure why it only happens on Node 8 & 10, but the issue is that by changing the cwd to be outside of the projects folder, when looking for plugins eslint
looks into the node_modules
in /tmp/eslint-plugin-jest-<tmpdir>
while using the config from eslint-plugin-jest
, and so fails to find all its plugins.
I hacked this together to confirm, so now I'll break it out into another PR, and then after that I should be able to merge & ship a bunch of our open PRs.
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.
On an aside, is there anything we could do in jest
core to improve process.chdir
support?
One such idea that comes to mind would be to do that I'm doing here: "pin" the cwd as part of jest
's setup phase, and then somehow make that available in places; or maybe even just using that as a mechanism to allow jest
to spot it's changed, and give people a warning.
I'm not sure how worth it would be, but if there are any low hanging fruit that could be done to even just reduce a few of the assumptions, I'd be happy to explore :)
1f5e5db
to
d8fe52e
Compare
This is based off #591 so that tests pass consistently, so that PR should be merged first. I enabled I also used |
🎉 This PR is included in version 23.14.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
I made a new eslint plugin for linting config files to check they're invalid, and for use of deprecated rules.
There's actually a couple of commits, but wanting to test out github actions annotations.