React-hooks-testing-library: TypeError: Cannot read property 'createElement' of undefined

[jensbodal]

I just spent the better part of a day figuring out an issue we had, and while it is not an issue with this package per se, it had to do with a misconfigured jest config file and the fact that @testing-library namespace can also contain a package called react. I would imagine this could happen anywhere that module resolution can be specified (jest, webpack, babel, tsconfig, etc.).

Problem

When using both @testing-library/react and @testing-library/react-hooks, renderHook method throws an error:

TypeError: Cannot read property 'createElement' of undefined

Actual problem

jest.config.js was configured with the following moduleDirectories:

moduleDirectories: ['node_modules', '.'],

Suggested solution

moduleDirectories: ['node_modules', 'src'],
moduleNameMapper: {
    '^src(.*)$': '<rootDir>/src$1',
};

Essentially what was happening before, when renderHook was called it would resolve require('react') to the closest react module, which ended up being @testing-library/react.

Another solution would be to explicitly define the react module, but this seems less correct.

moduleDirectories: ['node_modules', '.'],
moduleNameMapper: {
    "^react(.*)$": "<rootDir>/node_modules/react$1", 
};

This issue can be closed. Thank you.

[mpeyper]

I'm still confused as to what happened and why, but I assume you've raised this for others to find if they're in the same scenario (which is very kind of you) and there's nothing for me to actually do on this (let me know if I'm wrong about that).

Closing.

[jensbodal]

Yep it can be closed and I was just adding it for potentially anyone else since I found 0 topics on this problem.

Jest allows you to override module resolution. By specifying . as one of the places to resolve modules from, it essentially means resolve from the current directory and then up of wherever the require statement comes from.

./node_modules/react/index.js
./node_modules/@testing-library/react
./node_modules/@testing-library/react-hooks

Inside ./node_modules/@testing-library/react-hooks, ./node_modules/@testing-library/react is the closest module named react, so it was using that as the module for react instead of actual react.

@testing-library/react-hooks was being used along with react-testing-library. I ran into this issue while upgrading react-testing-library to @testing-library/react.

[mpeyper]

Oh, now I get it. Thanks for the explanation.

Cc @testing-library/react about this, in case it ever comes up in your issues too. I think in this scenario they would resolve to themselves when trying to resolve react too.

I'm not sure how many other testing libraries also reference react too? Perhaps @testing-library/react-native?

[jensbodal]

I doubt this issue will be very prevalent unless there’s somewhere out there suggesting to set a module resolution path to ..

But sure anywhere under @testing-library/ scope that requires react that has a similar module resolution strategy would likely have the same issue, and possibly this is isolated to how jest handles it.

I didn’t dive further into the issue than what was necessary to fix it.

[jensbodal]

So I encountered this problem again, it seems like a more robust fix is ensuring that root node_modules is used before any other node_modules

moduleDirectories: ['node_modules', '<rootDir>/node_modules', '.'],

Would this be a correct assumption that it would solve the same issue? It is working for me and I have removed the other entry from moduleNameMapper and seems to be working good.

Again not exactly related to react hooks but this is coming up in search results for others so thought it would be good to add. The issue surfaced again when I was testing using a symlinked dependency I was working against. I found the recommendation here: https://github.com/just-jeb/angular-builders/issues/657#issuecomment-573356703

[mpeyper]

ensuring that root node_modules is used before any other node_modules

I would have though that goes against the desired behaviour of node module resolution where dependencies are nested when there are version conflicts. I'm by no means an expert on this issue or the configurations options being described here, so please correct me if I'm wrong, but perhaps ['node_modules', '<rootDir>/node_modules', '.'] is closer to standard resolution order (i.e. nested node_module first, then a deduped/root module, then a sibling module)? Maybe?

[jensbodal]

Yeah I was actually thinking about this over the weekend and your comment is what I was thinking as well -- this would seem to go against the way module resolution is supposed to work. It _should_ work but I'll verify tomorrow.

[jensbodal]

Updated my comment, ['node_modules', '<rootDir>/node_modules', '.'], solves the issue as well and is more correct. Thanks for the reply!