Unable to use msw/node for testing solid-js due to `resolve.conditions` set to `browser` about msw

[kettanaito]

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.

[nknapp]

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.

[nknapp]

@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....

[nknapp]

@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 with Error: [commonjs--resolver] No known conditions for "./node" specifier in "msw" package
• vitest works fine.

Would be nice if you could reopen this issue.

[MarkLeMerise]

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"
}