Comments (5)
Hi, @nknapp. Thanks for reporting this.
You must configure your tooling to use the node
resolve condition in a Node.js process, which is correct. Resolving dependencies using a browser
condition while running in Node.js is a bad idea. I understand why tools try that but it's a shortcoming of the design. It should at least be ['browser', 'node']
. If you can control this, set the array of resolve conditions to include node
as well. If you can't control this, raise and issue in the respective tooling. You can link this comment there, and I'd be more than happy to explain why people should not use browser
export condition in Node.js.
MSW uses the conditional exports correctly: you must not import msw/node
in the browser. We cannot point that browser condition to a Node.js build, that'd blow things up on correct usage.
from msw.
Thanks, I have opened an issue with the plugin and will try your workaround.
As I said there. I think it is debatable. Since the user has to explicitly import msw/node
, I don't see the necessity to set browser
to null. The import makes it already clear that it is supposed to be used in Node.
from msw.
@kettanaito I have tried your suggestion and modified vite-plugin-solid
to set ['browser', 'node']
as conditions.
This still does not work, because the resolve.exports code iterates the keys of the export definition and returns the first matching key, which is browser
. If browser
were the last key in the exports definition, or if instead of browser: null
, you would omit the browser
key completely, then at least msw would work with ['browser', 'node']
.
I haven't tried though, if testing solidjs components would work as well....
from msw.
@kettanaito I got some more insight and a better solution.
The resolution algorithm will iterate the keys of the exports object and take the first match. The order or keys is significant (see this answer in the resolve.exports
repo.
For msw/node
this means that even if node
is in the conditions, as long as browser
is in there as well, the resolution will fail, because browser
comes before node
in the exports object.
If you intend resolution to fail for browser builds and succeeds for Node.js, it should look like this:
"./node": {
"types": "./lib/node/index.d.ts",
"node": {
"require": "./lib/node/index.js",
"import": "./lib/node/index.mjs"
},
"browser": null,
"default": "./lib/node/index.mjs"
},
First look for 'node" and succeed. Then look for "browser" and fail.
I have updated my reproduction example https://github.com/nknapp/msw-solid-testing-library-bug-reproduction to
patch msw
with these updated objects.
vite build
fails withError: [commonjs--resolver] No known conditions for "./node" specifier in "msw" package
vitest
works fine.
Would be nice if you could reopen this issue.
from msw.
Thanks for all the work you did narrowing down this issue, @nknapp. As it happens, I just finished a migration from msw
1.x -> 2.x.
// server.ts
import { setupServer } from "msw/node";
import { handlers } from "./handlers";
export const server = setupServer(...handlers);
But, I am seeing a similar error when running vitest
:
No known conditions for "./ClientRequest" specifier in "@mswjs/interceptors" package
It looks like the key order in the main msw/package.json
now follows your recommendation, but msw/node_modules/@mswjs/interceptors/package.json
is still in its original order. I applied this patch by hand and my tests passed:
"./ClientRequest": {
+ "node": {
+ "require": "./lib/node/interceptors/ClientRequest/index.js",
+ "import": "./lib/node/interceptors/ClientRequest/index.mjs"
+ },
"browser": null,
"types": "./lib/node/interceptors/ClientRequest/index.d.ts",
"require": "./lib/node/interceptors/ClientRequest/index.js",
"import": "./lib/node/interceptors/ClientRequest/index.mjs",
"default": "./lib/node/interceptors/ClientRequest/index.js"
},
The main difference in my setup is the Vite ecosystem library versions are a bit older:
{
"vitest": "0.34.1",
"vite": "4.4.10"
"vite-plugin-solid": "2.7.0",
"solid-js": "1.7.12",
"msw": "2.2.14"
}
from msw.
Related Issues (20)
- The cookies object recevied in the handlers varies depending on the placement of the handler within the `setupServer` function. HOT 7
- Calls to worker.use() remove handlers to same endpoint with different method HOT 2
- Unable to use HttpResponse.error() with TypeScript HOT 3
- How do I implement MSW in a NextJS backend?
- Missing `await` in the getting started example section for fetch call HOT 4
- 'Cannot read properties of undefined (reading 'url')' when multiple browser tabs are open HOT 3
- Question: Should we use msw to mock server-side apis based on the request body? HOT 1
- Update Documentation to Include undici Compatibility Issues and Solutions HOT 1
- Allow opting out from automatic processing unhandled exceptions in handlers HOT 4
- Allow customization of network error HOT 1
- Update 2.x removeAllListeners documentation
- Uncaught SyntaxError: Unexpected string (at msw.js?v=2dd0a77b:2057:51) HOT 2
- Include GraphQL operation name in the unhandled request warning HOT 5
- Trying to pull body in POST mocks breaks mocking HOT 3
- Error: [MSW] Failed to locate the Service Worker registration.
- Issue when no response.url and request is undefined
- msw/node unable to intercept requests from fetch in undici HOT 8
- request.formData() fails with vitest and file HOT 8
- Make bad "Network behavior overrides" more obvious HOT 1
- Optional path parameters do not match correctly HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from msw.