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

Updated jest Matchers namespace declaration #161

Closed

Conversation

shadrech
Copy link

@shadrech shadrech commented Nov 9, 2019

What:

Jest namespace extension was out of date. The Matchers interface only accepts one generics variable

Why:

Though its stated as being deprecated I find once this is updated and I import as mentioned in docs typings work as expected

@gnapse
Copy link
Member

gnapse commented Nov 11, 2019

This seems to be at odds with #150. The change you're trying to introduce here is the exact opposite of that other PR. Can you read over that PR's description and the reasoning of why this was done? Because that one seem to suggest that what you want to introduce here is what's really out of date. Maybe we can involve the author of that PR in the discussion (@bopfer) as well as @jgoz who approved it.

@bopfer
Copy link
Contributor

bopfer commented Nov 11, 2019

#150 was done to sync up with @types/jest. This comment explains the reasoning: DefinitelyTyped/DefinitelyTyped#39243 (comment)

@jgoz
Copy link
Collaborator

jgoz commented Nov 11, 2019

Yeah, #150 introduced an implicit dependency upgrade to the latest Jest typings. I was worried this would happen (user upgrades to latest jest-dom, but not jest typings), but we don’t currently have a way to communicate this implicit dependency.

Maybe we could add @types/jest as an optional peer dep?

@gnapse
Copy link
Member

gnapse commented Nov 14, 2019

user upgrades to latest jest-dom, but not jest typings)

Not sure what to do about this then, since either state of affairs affect some people.

Maybe we could add @types/jest as an optional peer dep?

Would that definitely solve the issue? Are there any downsides?

@jgoz
Copy link
Collaborator

jgoz commented Nov 14, 2019

user upgrades to latest jest-dom, but not jest typings)

Not sure what to do about this then, since either state of affairs affect some people.

I think it's simpler (for us) to always stay in sync with the latest Jest typings. My assumption is that people generally upgrade all jest-related packages together, including jest-dom.

Maybe we could add @types/jest as an optional peer dep?

Would that definitely solve the issue? Are there any downsides?

I wouldn't say it will "definitely solve" the issue since people can ignore peer dependency warnings, but it would at least provide some compatibility guidance for those using the typings.

@gnapse
Copy link
Member

gnapse commented Nov 14, 2019

Nice, seems reasonable.

@shadrech can you change this PR following what's discussed above?

@shadrech
Copy link
Author

Yh sure. Give me till the weekend and I'll work on it

@shadrech
Copy link
Author

Done @gnapse . Sorry for forced push. I had merged my local master branch which had some other changes I had made. Let me know if my changes suffice 👍

@gnapse gnapse requested a review from jgoz November 18, 2019 01:54
@shadrech
Copy link
Author

shadrech commented Jan 4, 2020

@jgoz Kindly review. Thanks

@gnapse
Copy link
Member

gnapse commented Jan 20, 2020

@jgoz how does this fare under the light of our recent work to fix #123? (context: #175, #182 and DefinitelyTyped/DefinitelyTyped#37792).

@jgoz
Copy link
Collaborator

jgoz commented Jan 20, 2020

This can be closed. Once the types are published to DT, they will have @types/jest as a dependency.

@shadrech shadrech closed this Jan 20, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants