Critical dependency: require function is used in a way in which dependencies cannot be statically extracted

[akunzai]

Prerequisites

• I confirm my issue is not in the opened issues
• I confirm the Frequently Asked Questions didn't contain the answer to my issue

Environment check

• I'm using the latest msw version
• I'm using Node.js version 14 or higher

Node.js version

v16.15.0

Reproduction repository

https://github.com/akunzai/react-boilerplate

Reproduction steps

yarn add msw@0.41.0
CI=true yarn build

Current behavior

The CI pipeline failed with warnings: Critical dependency: require function is used in a way in which dependencies cannot be statically extracted

Creating an optimized production build...

Treating warnings as errors because process.env.CI = true.
Most CI servers set it automatically.

Failed to compile.

Critical dependency: require function is used in a way in which dependencies cannot be statically extracted

and the warning was caused by ./node_modules/msw/lib/esm/index.js.

$ yarn start
Compiled with warnings.

Critical dependency: require function is used in a way in which dependencies cannot be statically extracted

Critical dependency: require function is used in a way in which dependencies cannot be statically extracted

Search for the keywords to learn more about each warning.
To ignore, add // eslint-disable-next-line to the line before.

WARNING in ./node_modules/msw/lib/esm/index.js 30:70-77
Critical dependency: require function is used in a way in which dependencies cannot be statically extracted

WARNING in ./node_modules/msw/lib/esm/index.js 33:45-52
Critical dependency: require function is used in a way in which dependencies cannot be statically extracted

webpack compiled with 2 warnings

Expected behavior

Run the CI pipeline successfully.

Creating an optimized production build...
Compiled successfully.

[piotr-cz]

Issue introduced in v0.41.0

[akunzai]

Workarounds to suppress the warnings

• set CI=false env on pipeline
• override Webpack config module.unknownContextCritical=false

Reference

• Webpack warnings trigger build errors when running on CI facebook/create-react-app#1150
• Critical dependency: require function is used in a way in which dependencies cannot be statically extracted CesiumGS/cesium-webpack-example#6
• https://marmelab.com/blog/2021/07/22/cra-webpack-no-eject.html
• https://stackoverflow.com/questions/38392697/webpack-umd-critical-dependency-cannot-be-statically-extracted

[baptistefkt]

I have same issue running my app on local. It's really annoying because @mswjs/data is using msw@latest so even if i downgrade this one, i will still get the error because @mswjs/data will use 0.41.0

[kettanaito]

@baptistefkt use resolutions (yarn) or overrides (npm) to pin msw package to 0.40.x.

[kettanaito]

Hey, @akunzai. Thanks for reporting this. I will take a look at what causes this issue when I have time. Anybody else is also welcome to tackle it—I think it's a matter of tsup (esbuild) configuration. Not sure what's going on wrong, as we're using default esm build format.

[akunzai]

Maybe the reason is that Webpack does not like UMD wrappers.

Not the fault of tsup or msw.

Reference

• https://www.npmjs.com/package/umd-compat-loader

[kettanaito]

Maybe the reason is that Webpack does not like UMD wrappers.

That'd be our fault if UMD slips through somehow. We've removed the UMD build target in 0.41.0.

The error originates from the esm target, which should not have any require statements. It'd be nice to explore that built module and see if it indeed has a require and see why so.

[jvzaniolo]

Same issue here

[kettanaito]

Please wait for the next release. You can see that there's a linked PR above and it fixes the issue. Thank you.

[jvzaniolo]

I'm using version 0.40 as suggested until then

[kettanaito]

Released: v0.42.0 🎉

This has been released in v0.42.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.

[nstepien]

I'm now getting 1 type issue with msw@0.42.0:

> tsc

node_modules/@mswjs/interceptors/lib/Interceptor.d.ts:1:26 - error TS7016: Could not find a declaration file for module 'debug'. 'D:/repos/Platform/OneStrata/OneStrata.Web/client/node_modules/debug/src/index.js' implicitly has an 'any' type.
  Try `npm i --save-dev @types/debug` if it exists or add a new declaration (.d.ts) file containing `declare module 'debug';`

1 import { Debugger } from 'debug';
                           ~~~~~~~


Found 1 error in node_modules/@mswjs/interceptors/lib/Interceptor.d.ts:1

🤷‍♂️

[kettanaito]

@nstepien, that seems to be related to #912. We don't ship ESM right now but the overall debug as a dependency is still pending. You can skip lib check if that blocks you or revert to a previous version. I'd like to have this resolved but I need help in looking into this properly.

[nstepien]

FWIW we publish react-data-grid as both cjs and esm and it's been working well for us, maybe you can take inspiration from our rollup/package.json config:
https://github.com/adazzle/react-data-grid/blob/main/rollup.config.js
https://github.com/adazzle/react-data-grid/blob/76030e6ef8ae775f56a22179935b925955ea62d6/package.json#L12-L23

[kettanaito]

Thanks for the reference, @nstepien!

We've been using Rollup in MSW for quite some time, and there were no issues with its ESM build (the debug issue is caused by the way we structure dependencies). I've migrated to tsup recently, getting a tremendous build time improvement. I'm reluctant to get back to Rollup but I wonder how the ESM produces by those two tools differs.

[maxarias-io]

@kettanaito Running into this with msw@0.49.1 in Nuxt Bridge as well:

WARN  in ./node_modules/msw/lib/node/index.mjs

Critical dependency: require function is used in a way in which dependencies cannot be statically extracted

Here's the code:

[kettanaito]

Thanks for your patience, everyone. I'm looking into this issue, trying to wrap my head around what exactly is the root cause here. This is reliably reproducible on the with-msw Next template.

The import path that causes the webpack warning is:

../../mswjs/msw/node_modules/.pnpm/@mswjs+interceptors@0.22.10/node_modules/@mswjs/interceptors/lib/node/chunk-62KFIM4W.js
../../mswjs/msw/node_modules/.pnpm/@mswjs+interceptors@0.22.10/node_modules/@mswjs/interceptors/lib/node/index.js
../../mswjs/msw/lib/core/utils/matching/matchRequestUrl.js
../../mswjs/msw/lib/core/index.mjs
../../mswjs/msw/lib/node/index.mjs
./mocks/server.ts
./mocks/index.ts

This comes down to the import { getCleanUrl } from '@mswjs/interceptors in the MSW code. Since that points to the Interceptor's root export, webpack will evaluate everything before resolving the getCleanUrl function (which is pure by itself, no imports).

Previously, we solved this by importing the getCleanUrl function directly from the Interceptors build, but that's not reliable because build paths are implementation details.

I think the correct solution here is to figure out what kind of output webpack wants. From what I can tell, it's a bit odd that an ESM import to lib/core/index.mjs continues with a CJS import to /matchRequestUrl.js. Maybe if this entire import path included ESM modules only, the issue would be gone?

Proposed solution

I confirm that if the entire import path of ESM contains modules referenced by .mjs explicit extension, the critical dependency issue is gone.

So, what happens is that somewhere along the import chain of ESM resolution a CJS module gets imported. It contains require statements, and so webpack complains about those.

[kettanaito]

The solution is implemented in https://github.com/mswjs/msw/blob/1f12ad9bef1808518ba9608143daf285403cea45/config/plugins/esbuild/forceEsmExtensionsPlugin.ts and will be published alongside the Fetch API primitives support in the next major version. Unfortunately, I don't have the time capacity to ship a backport for this because this requires a total library restructure and I'd pretty much like to do it just once. Thanks.