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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(jest-expect): re-export Matchers and MatcherFunctionWithState interface #12418

Merged
merged 5 commits into from
Feb 17, 2022
Merged

feat(jest-expect): re-export Matchers and MatcherFunctionWithState interface #12418

merged 5 commits into from
Feb 17, 2022

Conversation

mrazauskas
Copy link
Contributor

@mrazauskas mrazauskas commented Feb 17, 2022

Summary

Perhaps jest-expect should re-export Matchers interface as well?

I was looking at the example again. Feels like Jest users should be recommended to extend interfaces from '@jest/expect' instead of 'expect'. Right? In this case Matchers must be re-exported from jest-expect.

Also MatcherFunctionWithState is also useful. It is just the same as MatcherFunction, but takes two generic type arguments (state and matcher args) instead of one (only matcher args). I guess in most of the cases MatcherFunction will do the job, but for more advance usage MatcherFunctionWithState will be helpful too.

Other problem. Because of augmentation the example was pulling types from test type files. Ups.. I added minimal tsconfig.json, which helps to isolate the example.

Test plan

Green CI.

@SimenB
Copy link
Member

SimenB commented Feb 17, 2022

Hmm, it depends! Are the matchers for Jest specifically, or expect (which can be used anywhere standalone, like in mocha) generically?

Snapshots need runtime support, so makes sense for them to be separate, but I'd assume most matchers doesn't need that and can safely extend the base expect?

Doesn't hurt to re-export of course, but unsure of changing the example

@mrazauskas
Copy link
Contributor Author

Agreed. The example is reverted.

@@ -5,8 +5,7 @@
* LICENSE file in the root directory of this source tree.
*/

import {expect} from '@jest/globals';
import type {MatcherFunction} from 'expect';
import {type MatcherFunction, expect} from 'expect';
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about this? If 'expect' is extended later, perhaps importing from 'expect' here makes sense? Or?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

agreed!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

at least, I agree if this example is "extend expect" and not "extend jest with extra matcher". In that case people should import from @jest/globals (or use the global whenever we fix that)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm.. Perhaps I will revert this. In my head this was "extend jest with extra matcher" example. I mean, there is an extra file where this new matcher is used in a test. If expect was extended not for Jest, then expect(100).toBeWithinRange(90, 110); line in this file would be enough without extra test file. It makes sense to import from '@jest/globals'.

Copy link
Member

@SimenB SimenB Feb 17, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

We should work on https://jestjs.io/docs/expect to give better examples there probably, but keep this example as is

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed (;

Copy link
Member

@SimenB SimenB left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@SimenB SimenB merged commit bb09565 into jestjs:main Feb 17, 2022
@mrazauskas mrazauskas deleted the expect-expose-Matchers branch February 17, 2022 09:32
@SimenB
Copy link
Member

SimenB commented Feb 17, 2022

Out in https://github.com/facebook/jest/releases/tag/v28.0.0-alpha.3 fwiw

@github-actions
Copy link

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 20, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants