-
-
Notifications
You must be signed in to change notification settings - Fork 224
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
Delete expect and jest-matcher-utils dependencies #332
Delete expect and jest-matcher-utils dependencies #332
Conversation
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.
looks great! I have a couple of suggestions to reduce the diff, but the migration itself LGTM. I only commented in the first file, but the comments apply to them all
src/matchers/toBeAfter/index.js
Outdated
|
||
const failMessage = (received, after) => () => | ||
matcherHint('.toBeAfter', 'received', '') + | ||
const failMessage = (received, after, context) => () => |
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.
const failMessage = (received, after, context) => () => | |
const failMessage = (received, after, { matcherHint, printReceived }) => () => |
etc? again, to reduce diff
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.
It would reduce diff, but I thought it was kinda nice that the matchers all followed the same pattern of all using context
(although will now be utils
when I make that change).
jest-extended/src/utils/index.js Line 1 in 0013709
|
Where does the |
yeah, it cannot be imported like this, the matcher must inject it into the helper functions |
Got it. Made that change. |
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'll rebase this since I've introduced a conflict in pretty much all files 🙈
Codecov Report
@@ Coverage Diff @@
## main #332 +/- ##
==========================================
Coverage 100.00% 100.00%
==========================================
Files 137 109 -28
Lines 843 643 -200
Branches 143 100 -43
==========================================
- Hits 843 643 -200
Continue to review full report at Codecov.
|
Seems this failed CI, could you rebase to retrigger? |
Rebased, but the asymmetric matchers still aren't working. |
Right, so the failure is (imo) a bug in Jest. I've opened up a PR over there (jestjs/jest#11926), but unfortunately that means we can't really land this PR without breaking everybody using the matchers as asymmetric ones. |
We could tho, and just say that to use the asymmetric matchers you need to use Jest 27.x (whichever version it is when I make a release)? /cc @rickhanlonii thoughts? |
Could we release a new major of jest-extended instead? |
That's easiest, yeah 🙂 |
Jest versions older than v27.2.5 fail because they lack the asymmetric matchers fix. |
Yep, so we need to drop those versions from CI and update the peer dependency range before landing |
Replaced by #405 (because I'm no longer able to push to my fork after having deleted it). |
What
Don't depend on expect and jest-matcher-utils directly.
Why
utils are already injected into all the matchers.
Notes
Housekeeping