Webpack should have a way to ignore `require` calls

Bug report

What is the current behavior?

Webpack tries to handle all require() calls, even those not meant for browser usage. This makes it almost impossible to have a module that works in both Node.js and the browser, but has some added capabilities in Node.js.

Note that this is about authoring reusable npm packages, not end-user apps. I don’t have the ability to set any Webpack config like the externals option since I’m making packages other devs will consume.

This is the kind of awfulness we have to do because of Webpack: https://github.com/sindresorhus/ow/blob/d62a06c192b892d504887f0b97fdc842e8cbf862/source/utils/node/require.ts We have wasted countless of hours on this.

Prior discussion that went mostly ignored by the Webpack team: https://github.com/webpack/webpack/issues/196#issuecomment-354900072

What is the expected behavior?

I expected to be able to annotate the code to make Webpack ignore certain require() calls.

For example with a comment:

const require('chalk'); // webpack-ignore

I know for certain that this require() call will not be used in the browser, so I should be able to have it in my source code without Webpack printing warnings to users or erroring out.

I need this as a module maintainer (not user).

Telling users to use the externals config is out of the questions, as my package might be a dependency many levels down.

Some more examples of where I have to use awful code to work around Webpack:

• https://github.com/sindresorhus/file-type/pull/187/files#diff-168726dbe96b3ce427e7fedce31bb0bcR923

Other relevant information: webpack version: 4.29.0 (applies to any version though) Node.js version: 10.15.0 Operating System: macOS 10.14.3 Additional tools:

[sindresorhus]

However, I don’t think that webpack is to blame for this either. Dynamic imports is something no bundler is able to handle in a good way.

This is not about dynamic imports.

If webpack did not print out a warning for dynamic requires, people might get “Could not find module xyz” on runtime which is worst imo.

No, they would not get “Could not find module xyz” at runtime because the require call would be behind a conditional that is never hit in the browser. I’m asking for a way to tell Webpack to ignore a require() call because I know best. When automatic behavior fails, we should be able to override it.

I see the magic comment as a last resort because it’s webpack specific. I would like to have something that works with all bundlers.

The browser field in package.json is not a standard either. We could come up with a universally recognized magic ignore comment.

The browser field in the package.json is something that all bundlers respect.

Do you have a source for that assertion? Can you point me to the Webpack docs about the browser field?

So you would have two entries in your module, one that is intended for browsers and one that is intended for node. Then you would require all node-only dependencies in your main entry.

You’re asking me to massively refactor my codebase to support Webpack. It’s not as easy as just using the browser field. It would mean creating entry points that can easily be swapped out. It’s not always that simple.

All I want is to make Webpack ignore a require call that is not used in the browser…

[techhead]

For anyone else encountering this issue and need a workaround, this is probably the best one: https://twitter.com/kamilogorek/status/1102272038411137025

This is what I ended up going with for doing a conditional import in the NodeJS environment.

const nodeVer = typeof process !== "undefined" && process.versions?.node;
const nodeRequire = nodeVer
  ? typeof __webpack_require__ === "function"
    ? __non_webpack_require__
    : require
  : undefined;

Webpack will optimize away the bare require in this case so that you don’t end up with the ugly warning below (and extra code injected).

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