Warn about assertion name collisions between 2 libs extending jest
See original GitHub issue🚀 Feature Proposal
Warn users when they have two matchers with colliding names. (and one is being overwritten silently)
Motivation
At the moment there is the case with jest-extended and testing-lib/dom.
Both libraries have an assertion called toBeEmpty.
In jest-extended, it checks for emptiness in data, in testing-lib/dom, it checks for emptiness in the DOM.
https://github.com/testing-library/jest-dom#tobeempty https://github.com/jest-community/jest-extended#tobeempty
The situation is that as developers add both libraries in the project, one of the toBeEmpty will be silently overwritten, and when they start using them in their unit tests, and the test does not pass, regardless of being empty, they will not know what the problem is.
As there is no mechanism to decide which assertion names are already taken by libraries extending jest, an option to handle this, would be to warn users, as they install or run their tests, with 2 assertion names colliding, that the collision is happening, so that they can rename one of both in their projects
In my case I did by doing this as a very quick and dirty fix:
import {
toBeEmpty as toBeEmptyNode,
} from '@testing-library/jest-dom/matchers';
expect.extend({ jestDomToBeEmpty });
Idea
I dont know the codebase in Jest to give more specific ideas, what I am thinking is, as they run their tests, to show a warning telling them that these 2 libs are using the same name for a matcher, and give them a link to find a solution to rename one in their configs.
For reference
I reported this in the author’s libs, before deciding how to address this, would be helpful to read your thoughts on it.
Issue Analytics
- State:
- Created 4 years ago
- Reactions:1
- Comments:5

Top Related StackOverflow Question
Yes, both issues are highly related, but one may handle them separately. While #6243 addresses possible solutions, this issue talks about adding a warning (which might still be a good idea even after #6243 is implemented).
Related to (or duplicate of) #6243