-
Notifications
You must be signed in to change notification settings - Fork 234
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(no-deprecated-functions): remove process.cwd
from resolve paths
#889
Conversation
hmm ok maybe that's why I added it, so we could test properly? I think we could get almost the best of both worlds by instead doing:
But there's one test that still fails. I'll have to do some thinking and playing around to see what we can do - I'd like to avoid adding a really big e2e-type setup where we copy around a bunch of files if possible but maybe that's what we have to go with? |
I think we should just remove it and throw an error if people use this rule without specifying the version of Jest they use. They can easily do this in their own |
Please update the documentation to reflect this concept. It is uncommon to add a settings object to the |
Our docs are lacking an example of this, yeah |
I've made #897 expanding our documentation to explain this :) |
1158b43
to
60a796e
Compare
723cc9e
to
2269232
Compare
@G-Rath how's this one going? 😀 |
@SimenB go for gold on reviewing - there's some minor cleanup I was going to look to do once I got it all green (which it is now) but it's fine without it |
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.
this is missing handling of the user passing a string as the version in their settings (via a require('jest/package.json').version
)
Beyond that, looks good 🙂
// pin the original cwd so that we can restore it after each test | ||
// const projectDir = process.cwd(); | ||
|
||
// afterEach(() => process.chdir(projectDir)); |
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.
// pin the original cwd so that we can restore it after each test | |
// const projectDir = process.cwd(); | |
// afterEach(() => process.chdir(projectDir)); |
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.
hehe yeah this was the main "minor cleanup" I was going to do - I think we should be able to use changing the directory to remove the need to pass the projectDir
around, which might be nicer.
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.
So using process.chdir
does work, but tbh I don't know which is actually nicer: using it means we don't have to pass around the project directory argument in all of our tests, but then we'll be magically changing directories and so stuff "just works" 🤔
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
actually changes the dir, so I'd prefer not to
Glad you think so - I was pleasantly surprised with how nicely this turned out: while a little annoying we can't collect coverage from the process calls, the tests are fast & cleaner than before + we're not making nearly as many tmp directories as before (only ~4 vs "a whole bunch"). At some point I've been meaning to break our btw this change should mean we can technically switch to using |
Do you mean you'd like a test that explicitly has |
const detectJestVersion = (): JestVersion => { | ||
if (cachedJestVersion) { | ||
return cachedJestVersion; | ||
const parseJestVersion = (rawVersion: number | string): JestVersion => { |
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.
Technically this is duplicated in detectJestVersion
, but I'm fine with that as it's only a few lines and otherwise it calls into question a bit the JestVersion
& underlying function name which I don't think is worth doing right now.
It'll be easy enough to refactor in the future if we find more uses for this value and/or a use for having minor or patch versions.
# [24.5.0](v24.4.3...v24.5.0) (2021-09-29) ### Bug Fixes * **no-deprecated-functions:** remove `process.cwd` from resolve paths ([#889](#889)) ([6940488](6940488)) * **no-identical-title:** always consider `.each` titles unique ([#910](#910)) ([a41a40e](a41a40e)) ### Features * create `prefer-expect-resolves` rule ([#822](#822)) ([2556020](2556020)) * create `prefer-to-be` rule ([#864](#864)) ([3a64aea](3a64aea)) * **require-top-level-describe:** support enforcing max num of describes ([#912](#912)) ([14a2d13](14a2d13)) * **valid-title:** allow custom matcher messages ([#913](#913)) ([ffc9392](ffc9392))
🎉 This PR is included in version 24.5.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
# [25.0.0-next.5](v25.0.0-next.4...v25.0.0-next.5) (2021-09-29) ### Bug Fixes * **no-deprecated-functions:** remove `process.cwd` from resolve paths ([#889](#889)) ([6940488](6940488)) * **no-identical-title:** always consider `.each` titles unique ([#910](#910)) ([a41a40e](a41a40e)) * **valid-expect-in-promise:** support `finally` ([#914](#914)) ([9c89855](9c89855)) * **valid-expect-in-promise:** support additional test functions ([#915](#915)) ([4798005](4798005)) ### Features * create `prefer-expect-resolves` rule ([#822](#822)) ([2556020](2556020)) * create `prefer-to-be` rule ([#864](#864)) ([3a64aea](3a64aea)) * **require-top-level-describe:** support enforcing max num of describes ([#912](#912)) ([14a2d13](14a2d13)) * **valid-title:** allow custom matcher messages ([#913](#913)) ([ffc9392](ffc9392))
🎉 This PR is included in version 25.0.0-next.5 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Resolves #874
Resolves #886
Resolves #888
Would be good if people could test this locally on a few projects and in editors - I think it's fine, but want to make sure we've checked that it won't make any editors explode (as thats the primary reason for why this is here).