Skip to content
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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: do not explicitly depend on jest assertion utils #250

Merged
merged 3 commits into from Aug 22, 2020
Merged

fix: do not explicitly depend on jest assertion utils #250

merged 3 commits into from Aug 22, 2020

Conversation

SimenB
Copy link
Contributor

@SimenB SimenB commented May 13, 2020

What:

Replaced the direct usage of jest-matcher-utils and jest-diff with using the same functions from this.utils injected into each matcher.

Why:

I noticed I had old jest-diff in my node_modules after upgrading to v26 and decided to fix at least one of the entries 馃檪

This change allows jest-dom to not depend on explicit versions of these dependencies, instead getting the utils from expect during runtime.

How:

Search and replace, followed by making the linter happy 馃榾

Checklist:

  • Documentation
  • Tests
  • Updated Type Definitions
  • Ready to be merged

README.md Outdated Show resolved Hide resolved
@codecov
Copy link

codecov bot commented May 13, 2020

Codecov Report

Merging #250 into master will not change coverage.
The diff coverage is 100.00%.

Impacted file tree graph

@@            Coverage Diff            @@
##            master      #250   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           23        23           
  Lines          315       315           
  Branches        72        72           
=========================================
  Hits           315       315           
Impacted Files Coverage 螖
src/to-be-checked.js 100.00% <酶> (酶)
src/to-be-disabled.js 100.00% <酶> (酶)
src/to-be-empty-dom-element.js 100.00% <酶> (酶)
src/to-be-empty.js 100.00% <酶> (酶)
src/to-be-in-the-dom.js 100.00% <酶> (酶)
src/to-be-invalid.js 100.00% <酶> (酶)
src/to-be-partially-checked.js 100.00% <酶> (酶)
src/to-be-required.js 100.00% <酶> (酶)
src/to-be-visible.js 100.00% <酶> (酶)
src/to-contain-element.js 100.00% <酶> (酶)
... and 12 more

Continue to review full report at Codecov.

Legend - Click here to learn more
螖 = absolute <relative> (impact), 酶 = not affected, ? = missing data
Powered by Codecov. Last update 92176e1...64fff15. Read the comment docs.

@eps1lon
Copy link
Member

eps1lon commented May 13, 2020

This change allows jest-dom to not depend on explicit versions of these dependencies, instead getting the utils from expect during runtime.

So we'd need a peer dependency on jest, no?

@SimenB
Copy link
Contributor Author

SimenB commented May 13, 2020

Not, it's expect that injects these, not Jest. You already call expect.extend without a peer dep on it. And you already depend on e.g. this.isNot so in that regard this PR changes nothing. This maybe couple the matchers more to expect so they cannot be plugged into jasmine if that's a concern? expect itself can be used as assertion library for any runner

@SimenB
Copy link
Contributor Author

SimenB commented Aug 13, 2020

@gnapse any holdup here?

@gnapse
Copy link
Member

gnapse commented Aug 13, 2020

Nope, my bad. Will merge soon.

@gnapse
Copy link
Member

gnapse commented Aug 13, 2020

@SimenB there have been a couple of new matchers since you proposed this change. I can take care of it later if you don't beat me to it.

@SimenB
Copy link
Contributor Author

SimenB commented Aug 22, 2020

@gnapse updated

@SimenB SimenB changed the title feat: do not explicitly depend on jest assertion utils fix: do not explicitly depend on jest assertion utils Aug 22, 2020
@eps1lon eps1lon merged commit 2da8c71 into testing-library:master Aug 22, 2020
@eps1lon
Copy link
Member

eps1lon commented Aug 22, 2020

@SimenB Thanks!

@gnapse
Copy link
Member

gnapse commented Aug 22, 2020

馃帀 This PR is included in version 5.11.4 馃帀

The release is available on:

Your semantic-release bot 馃摝馃殌

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants