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

Is Expect extensible? #82

Open
a-gierczak opened this issue Nov 16, 2020 · 2 comments
Open

Is Expect extensible? #82

a-gierczak opened this issue Nov 16, 2020 · 2 comments

Comments

@a-gierczak
Copy link

a-gierczak commented Nov 16, 2020

Hello, thanks for the bindings!
I've looked into the code and as far as I can see, the Expect module creates jest assertions via assertion variant. This makes the API clean, but doesn't really allow users to introduce custom matchers. E.g. we use jest-dom and testing-library/jest-native and we weren't been able to properly cooperate the custom matchers with Expect module.

@leoparis89
Copy link

leoparis89 commented May 18, 2022

Hello, thanks for the bindings! I've looked into the code and as far as I can see, the Expect module creates jest assertions via assertion variant. This makes the API clean, but doesn't really allow users to introduce custom matchers. E.g. we use jest-dom and testing-library/jest-native and we weren't been able to properly cooperate the custom matchers with Expect module.

Same problem here.
I had to vendor this library and add the extra needed matchers.
Would love to know if the author recommends a solution better than forking the library and adding the matchers.
Anyways thanks for this work.

@glennsl
Copy link
Owner

glennsl commented May 19, 2022

It should be possible to create a custom asserter and awkwardly re-exposing and forwarding the original assertions to the default asserter. But it wasn't really designed for extensibility, even if that's long been desired. It would likely require a complete rewrite of the internals, and I don't have time to do that. But I would certainly welcome efforts to do so while at the very least retaining the design philosophy, if not the API.

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

No branches or pull requests

3 participants