-
-
Notifications
You must be signed in to change notification settings - Fork 517
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
Jest : Cannot find module 'msw/node' from ... #1809
Comments
@PanchoutNathan from that repo it looks like you may not have seen this https://mswjs.io/docs/migrations/1.x-to-2.x/#cannot-find-module-mswnode-jsdom in the docs for the migration from 1.x to 2.x. Let us know if this doesn't help resolve your issue here! I'm going to close, assuming this should fix the issue, but please reopen if it does not |
@mattcosta7 Setting The real issue is how the In the msw package.json, there are the following lines: Lines 16 to 17 in ea28bd9
Lines 23 to 24 in ea28bd9
Lines 30 to 31 in ea28bd9
Why is msw specifing an environment that doesn't exist? The The issue is that resolvers such as I know this is a little hard to read, but it reads along the lines of this:
So there are two ways to resolve this issue:
I'm not aware of any reason why having an environment condition with a null entry would be required in the exports. If there is, please share cause I am trying to expand my knowledge of ESM ❤️ |
@PanchoutNathan - I'd re-open this as a bug |
This comment was marked as outdated.
This comment was marked as outdated.
Quick response just explaining the reasoning here setupServer is not actually valid in a browser Since these require globals from specific environments the null values block them and lead to build instead of runtime errors. Jests jsdom environment resolves using browser exports, which makes this more complicated, and ideally the suggestion is to configure jest to use the node import instead of the browser one for msw. In jest/jsdom msw still needs to operate as if it's running in node and not as if it's running in a browser. It's a bit complicated. A custom resolver can be configured to do this, and patch package can remove the null or configure it differently. |
I understand that this is turning into a bit of a Holy War and I've see the comments in issues like #1787 & #1786. However... I still feel that there is a bug here. I have spent an extensive amount of time debugging issues related to msw in my environment (vast majority not msw). I've also created an "extension" to msw to add some functionality I needed. (read I've been deep in the weeds with msw for the last week) All that to say, I've resolved this import issue (at least for my use cases) locally -> without touching any of the jest settings. In my initial assessment I was wrong about one thing: When the export resolver looks up a subpath and tries to match conditions it is going in object key order of the export object not the conditions as I previously thought. This matters because the problem is unidirectional, meaning the problem is dealing with "browser like" in node and never "node like" in the browser. Therefore, if you change the order of the conditions in the export objects the issue is resolved. I'm including an updated patch below, please give it a try because if I am wrong I would love to understand why! ❤️ |
Note the order of conditions in each export subpath. Importantly, Also, I updated the stub package.json's (i.e
Note: This change is required in both |
I'm away for a bit still, but with these changes the browser and node conditions will never be satisfied Import and/or require will resolve in either environment, so browser and node would never be used Export conditions resolve in order, and the first matching condition is used, not the best matching one |
Damn, you are correct. Ok, last attempt here before I throw in the towel... -> Why not use consistent nested subpath definitions instead of having top level require/import. Meaning, instead of:
Do:
This way, priority is always given to node and it is still returning null for the browser in the necessary places... ? (My assumption is that true browser environments will never have any condition other than browser.) Also are you aware of any situations where the environment conditions contain neither Also apologies for my persistence on this, msw has been a huge help to us and ultimately just trying to make it easier for folks to use ❤️ PS- Happy new year to those on the Gregorian calendar! |
Alright, throwing in the towel... While that idea in theory would work, because its JSDOM, the resolvable conditions are Shucks, appreciate you humoring me on this |
I updated my jest.config.js file as suggested for this error https://mswjs.io/docs/migrations/1.x-to-2.x#cannot-find-module-mswnode-jsdom in my code but I still get My config file
|
Prerequisites
Environment check
msw
versionNode.js version
18.18
Reproduction repository
openfun/joanie#445
Reproduction steps
yarn test numbers
Current behavior
● Test suite failed to run
Expected behavior
There were no issues before upgrading to 2.0.1. The tests should run correctly.
The text was updated successfully, but these errors were encountered: