You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When both libs are used in the same project, in my case the version of jest-extended overwrites the one from jest-dom. But this might vary depending on the order used to add the libs
Describe alternatives you've considered:
Maybe an option is to add an alias for toBeEmpty named toBeEmptyValue or something ?
I am not sure at this moment how the things work, could it be an option to have 2 names for the same assertion?
If yes, then the documentation could say:
"if you are using jest-extended, then use toBeEmptyValue" or something like this
However, I have raised a feature request in Jest Itself asking for a feat that warns the user about the name collision and points out to a link where is documented a way to rename one of the colliding names in the project where the situation happens.
It could be that the warning and the documentation of how to solve it in projects, might be enough to address this and similar situations like this one.
The text was updated successfully, but these errors were encountered:
DanielaValero
changed the title
ToBeEmpty matcher in jest-dom is also used in jest-extended
ToBeEmpty assertion in jest-extentended collides with jest-dom's one
Mar 17, 2020
DanielaValero
changed the title
ToBeEmpty assertion in jest-extentended collides with jest-dom's one
ToBeEmpty assertion in jest-extended collides with jest-dom's one
Mar 17, 2020
Describe the feature you'd like:
Jest-Extended has an assertion named the same as jest-extended's one:
-> https://github.com/jest-community/jest-extended#tobeempty
-> https://github.com/testing-library/jest-dom#tobeempty
When both libs are used in the same project, in my case the version of
jest-extended
overwrites the one from jest-dom. But this might vary depending on the order used to add the libsDescribe alternatives you've considered:
Maybe an option is to add an alias for
toBeEmpty
namedtoBeEmptyValue
or something ?Teachability, Documentation, Adoption, Migration Strategy:
I am not sure at this moment how the things work, could it be an option to have 2 names for the same assertion?
If yes, then the documentation could say:
"if you are using jest-extended, then use
toBeEmptyValue
" or something like thisHowever, I have raised a feature request in Jest Itself asking for a feat that warns the user about the name collision and points out to a link where is documented a way to rename one of the colliding names in the project where the situation happens.
jestjs/jest#9678
It could be that the warning and the documentation of how to solve it in projects, might be enough to address this and similar situations like this one.
The text was updated successfully, but these errors were encountered: