Ethers.js: Webpack 5: Module not found: Can't resolve 'http'

[jadbox]

I'm importing ethersjs into my Nextjs SPA via import { ethers } from "ethers"; and I'm getting the below error:

```
error - ./node_modules/@ethersproject/web/lib.esm/geturl.js:11:0
Module not found: Can't resolve 'http'
````

Related to:
https://github.com/ethers-io/ethers.js/issues/349

[ricmoo]

You need to add "browser" as the first entry in your WebPack config. There is a browser property in the package.json that will replace that file with browser-geturl during bundle time for browsers.

Let me know if that helps or not. :)

[ricmoo]

(forgot to mention you need to add it to the "mainFields" property in the WebPack config)

[jadbox]

I got it working by yarn install http-browserify https-browserify and updating next.config.js to the below:

module.exports = {
  webpack: (config, { buildId, dev, isServer, defaultLoaders, webpack }) => {
    config.resolve.alias.https = "https-browserify";
    config.resolve.alias.http = "http-browserify";
    return config;
  },
};

It would be great if this was documented or have a simpler method to define the needed polyfills, as I'd imagine other developers will face the same problem upgrading to webpack 5.

[ricmoo]

You should be able to create a similar config that will alias "./geturl", with "browser-geturl", which would result in much more compact code (since you won’t need those dependencies, which I’m guessing are quite large).

This is all adding "browser" to the "mainFields" property does, but I’m not sure how to configure that in the JS config file. If you figure that out, let me know and I’ll add it to the docs. :)

Is your target web? It looks like it should pick them up in that case, but I’m not terribly familiar with WebPack. See: https://webpack.js.org/configuration/resolve/#resolvemainfields

I would love to include it in the docs though, if you can find a way to avoid pulling in those dependencies (they are the long way around; geturl -> http -> fetch compared to browser-geturl -> fetch)

[ricmoo]

(i.e. you shouldn’t need those polyfils because I’ve already implemented the functions as an alternate implementation for when the needed things being polyfilled don’t exist; you just need to let the bundler know they are there. ;))

[jadbox]

hey @ricmoo ! I'm a little lost here too as I think Nextjs should already be adding "browser" to mainFields, so I don't know why Nextjs is still complaining.
I also tried adding config.resolve.alias["./geturl"] = "browser-geturl" and config.resolve.alias["geturl"] = "browser-geturl" without success.

[jadbox]

Since I'm doing only static browser builds, I updated my config with this to just not polyfill over the node modules for the server build. I -think- the client build is working as it should as it gets the mainFields>browser flag.

config.resolve.alias["https"] = false;
config.resolve.alias["http"] = false;

[fritzschoff]

same issue here!

[jmrossy]

I hit this issue to when I upgraded my project from Webpack v4 to v5. The fix was to prepend browser to the webpack resolve.browser.mainfields array like @ricmoo suggested and also to import only from ethers directly like suggested in #349. Some more details:

The webpack build was complaining about the http, https, and zlib libraries:

BREAKING CHANGE: webpack < 5 used to include polyfills for node.js core modules by default.
This is no longer the case. Verify if you need this module and configure a polyfill for it.

First I tried I setting resolve.alias and/or resolve.fallback configs for those libs. That did silence the build errors but then ethers would throw network errors.

The real solution was to fix the mainfields config and also my imports. I.e. import {utils} from 'ethers' instead of import {whatever} from 'ethers/lib/utils'.

Fixing the imports also reduced my final bundle size considerably so this turned out to be a lucky error!

[cruzdanilo]

i got it working using only this webpack resolve config:

resolve: { aliasFields: ['browser', 'browser.esm'] }

[ricmoo]

Wow. I didn’t know you could specify non-standard fields. :p

That field is meant more as an internal build system flag.

I have a new build system nearly done which should make everything cooperate with webpack/rollup/etc. much better without these hacks... It’s coming. :)

[ricmoo]

This should be addressed in 5.0.20.

You should no longer need to specify mainFields in Webpack or rollup configs, as the module and browser fields point to pre-bundled/aliased clusters of files. And by splitting apart some libraries, tree-shaking seems much happier.

Try it ou and let me know. Thanks! :)

[ricmoo]

I'm hearing from various sources that these issues have been resolved, so I'm going to close this. Please re-open if you have any issues though.

Thanks! :)

[fritzschoff]

Thanks!