The issue arises from the fact that the regular expression in the moduleNameMapper is inadvertently capturing all the @mui styles as well, causing disruptions for @mui due to its inability to access the necessary theme provider and HOC styles that it relies on internally. This leads to @mui resorting to using an empty mocked object, resulting in a breakdown.
I explored various solutions involving jest.mock and attempting to mock out the styles/theme, but most of them proved to be impractical and ineffective.
In the end, I resolved the issue by modifying:
"moduleNameMapper": {
"style$": "<rootDir>/tests/mock.ts"
}
to:
"moduleNameMapper": {
"style.(scss)$": "<rootDir>/tests/mock.ts"
}
This change ensures that only my custom styles are excluded, leaving @mui unaffected. By allowing @mui to manage its own styles without interference when utilizing jest, one must exercise caution with moduleNameMapper to avoid mocking essential modules required by dependencies and selectively excluding only the necessary ones.
The unintended exclusion of all @mui elements by using "style" in the regular expression was rectified, allowing @mui to handle its styles independently and restoring seamless functionality.