feat: makes the library esm-compatible

[ivanhofer]

fixes #1267

I have investigated #1267 a bit. There are a few road blocks to make msw/node work in a .mjs file:

• reference lib/index.js instead of 'lib' in a few files (easy to achive)
• tsup does not support import assertions (needed here https://github.com/mswjs/msw/blob/main/src/context/status.ts#L1) import assertion get removed from output egoist/tsup#714
  workaround: feat: makes the library esm-compatible #1399 (comment)
• dynamic import of node-fetch (https://github.com/mswjs/msw/blob/main/src/context/fetch.ts#L6) is not supported in esm context. How to fix "Dynamic require of "os" is not supported" evanw/esbuild#1921
  workaround: feat: makes the library esm-compatible #1399 (comment)

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit 2755f43:

Sandbox	Source
MSW React	Configuration

[mattcosta7]

we should really just update interceptors to expose an esm build.

I started on that over the weekend, and have some thoughts on how we could do that, but I think we'll need to probably remove debug as a dependency there - since it relies on tty and os, and i'm having issues getting those properly bundled to a browser compat version, that multiple build tools like.

[kettanaito]

We need to look into some debug recipes perhaps. It has browser support, so it should run in the browser. Perhaps we can do some import map for this dependency to ensure that in the browser it always imports the browser dist.

[mattcosta7]

Yeah, it mostly relates to the fact that debug doesn't have an esm build, so loading in a browser directly from @web/dev-server seems problematic.

Maybe that just means users in those environments have to do some extra setup, and that's enough. Will keep playing with configurations there, because it's also possible we don't need to be as explicit there.

I was testing using tsup to bundle, however using tsc to generate cjs and esm transpilations might help avoid issues related to that (since it won't try to handle debug directly)

[mattcosta7]

dynamic import of node-fetch

I think we could get around this with something like

useFetch = isNodeProcess() ? (input, init) => import('node-fetch').then(({default: nodeFetch}) => fetch(input, init)) : window.fetch

I'm curious if we could also avoid using node-fetch directly in this library and just stipulate that globalThis.fetch be defined already (via a user polyfill) instead?

[ivanhofer]

With this branch it is now poosible to run the following esm file:

test.mjs

import { setupServer } from 'msw/node'

setupServer()

with the command

node ./test.mjs

[filipw01]

Nice, work. I was about to open an issue, but it looks like it should be fixed once this PR is merged 😄

[ivanhofer]

I think this PR is ready to be merged. Or is something still missing?

[mataspetrikas]

@kettanaito @ivanhofer is this coming into the next release?

[kettanaito]

Finally got to this improvement. Looks superb 🎉 Updated against the latest main, waiting for the CI before marking it as a release candidate. Expect to land in the next minor release.

Thank you for improving MSW, @ivanhofer! If you ever feel like exercising your skill again, we could also migrate the interceptors library to ESM.

[kettanaito]

The only thing I'd add is an automated test for the distributed ESM format. Let me see if I can dig out the previous test I've written...

[kettanaito]

Released: v0.48.0 🎉

This has been released in v0.48.0!

• 📄 Release notes
• 📦 npm package

Make sure to always update to the latest version (npm i msw@latest) to get the newest features and bug fixes.

---

Predictable release automation by @ossjs/release.