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(expect, @jest/expect): support type inference for toBe assertions #13470

Closed

Conversation

royhadad
Copy link
Contributor

@royhadad royhadad commented Oct 18, 2022

Summary

relates to #13334
This is a continuation of #13268, which was merged and reverted in #13339. It adds only one use case that should be safe.
It should improve developer experience by adding type inference for the types passed to the toBe assertion

Test plan

added automated tests

What do you guys think? @SimenB @mrazauskas

@royhadad royhadad changed the title Add type inference to to be matcher feat(expect, @jest/expect): support type inference for toBe assertions Oct 18, 2022
@mrazauskas
Copy link
Contributor

.not modifier is tricky part. See #13444 (review)

Comment on lines 224 to 227
expectType<void>(
expect({name: 'someName', age: 12}).toBe({name: 'someOtherName', age: 13}),
);
expectError(expect({name: 'someName', age: 12}).toBe({name: 'someOtherName'}));
Copy link
Contributor

Choose a reason for hiding this comment

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

Hm.. But both of these will fail at run time, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yep, both fail at run time
first one passes type checks
second one fails type checks

@royhadad
Copy link
Contributor Author

.not modifier is tricky part. See #13444 (review)

Changed the inverses to be unknown, I think this is good as this is the current behavior - so it should not do harm

@royhadad royhadad marked this pull request as ready for review October 18, 2022 14:54
@royhadad
Copy link
Contributor Author

I see some failing tests in TypeScript Compatibility, due to the new stricter type checking. Any idea how to go about fixing those?

@mrazauskas
Copy link
Contributor

See #13444. That is almost identical PR and got open first, so I left my comments there.

Also note that I reverted #13268. For motivation see #13339. After noticing these problems I am rather sceptical about type inference of matcher arguments.

@royhadad
Copy link
Contributor Author

Closing because it's a duplicate of #13444

@royhadad royhadad closed this Oct 23, 2022
@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 Nov 23, 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.

None yet

3 participants