URL is not a constructor (esm/commonjs differences)

[roderik]

Getting stuck on a really weird webpack/url issue

I have the most simple code ("@ethersproject/providers": "5.0.0-beta.164")

  import {JsonRpcProvider} from '@ethersproject/providers';

  const RPCProvider = new JsonRpcProvider(
    `https://xxx`
  );

Which fails with (on runtime, not compile time)

TypeError: url__WEBPACK_IMPORTED_MODULE_2__.URL is not a constructor
    at geturl.js:60
    at Generator.next (<anonymous>)
    at geturl.js:8
    at new Promise (<anonymous>)
    at push.../../node_modules/@ethersproject/web/lib.esm/geturl.js.__awaiter (geturl.js:4)
    at getUrl (geturl.js:52)
    at index.js:94
    at Generator.next (<anonymous>)
    at index.js:8
    at new Promise (<anonymous>)
    at push.../../node_modules/@ethersproject/web/lib.esm/index.js.__awaiter (index.js:4)
    at index.js:91
    at fetchJson (index.js:140)
    at JsonRpcProvider.send (json-rpc-provider.js:273)
    at JsonRpcProvider.<anonymous> (json-rpc-provider.js:218)
    at Generator.throw (<anonymous>)
    at rejected (json-rpc-provider.js:6)

and the corresponding code in geturl is

 import { URL } from "url";
 const url = new URL(href);

It picks the esm compiled versions, when I check the non esm versions it actually includes URL like so

Totally unclear on why this suddenly started happening though...

[roderik]

Reverting to 5.0.0-beta.162 and adding a network id gets me past this got me past this but it then failed on 'could not detect network'. It looks similar to #814

Both eth_chainId and net_version fail with "no response"
Curling returns the correct response though

Debugging deeper in the send method shows that we hit the same error

TypeError: url__WEBPACK_IMPORTED_MODULE_2__.URL is not a constructor
    at geturl.js:59
    at Generator.next (<anonymous>)
    at geturl.js:8
    at new Promise (<anonymous>)
    at push.../../node_modules/@ethersproject/web/lib.esm/geturl.js.__awaiter (geturl.js:4)
    at getUrl (geturl.js:52)
    at index.js:94
    at Generator.next (<anonymous>)
    at index.js:8
    at new Promise (<anonymous>)
    at push.../../node_modules/@ethersproject/web/lib.esm/index.js.__awaiter (index.js:4)
    at index.js:91
    at fetchJson (index.js:147)
    at JsonRpcProvider.send (json-rpc-provider.js:280)
    at JsonRpcProvider.perform (json-rpc-provider.js:373)
    at JsonRpcProvider.<anonymous> (base-provider.js:429)
    at Generator.next (<anonymous>)
    at fulfilled (base-provider.js:5)

[roderik]

Forcing web to 5.0.0-beta.136 fixies it

When using yarn workspaces, up this in the top level package.json

  "resolutions": {
    "@ethersproject/web": "5.0.0-beta.136"
  },

[ricmoo]

Oh, when upgrading the beta, you may need to remove the node_modules, package-lock.json and any other lock files (yarn, etc) then do an npm install.

This requirement will be going away soon. :)

[roderik]

I always do this, we run a quite complex monorepo with several active branches, it is a given to make sure you have the right one when stuff is wonkey.

In this case, I have several packages depending on some parts of the new separate ethers packages. They require web but with a >= version lock. So forcing a specific version of a sub dependency takes some effort (see workaround above)

But besides that, I have the strong suspicion that, at least in combination with a create-react-app / webpack frontend, the recent changes to web do not work.

[ricmoo]

Yes, a actually have a script to handle exactly that case, but that means updating every package version. Which maybe its a good time to do that anyways. :)

Does the react part use ESM or UMD? What if you import @ethersproject/web directly and use fetchJson? Same error?

[roderik]

It appears to be using the esm version.

But just to be clear so we are not focussing on the wrong issue :)

• latest version did not work
• the versioning issue comes into play when you try downgrading
• forcing the older version of web makes everything work again pointing firmly at the latest changes that make it break

[ricmoo]

Does your webpack config specify the "browser" field in the mainFields? Because the URL package is not used in any of the browser versions of the web packages... It sounds like it is pulling the node version in, instead of the browser version.

[ricmoo]

And what if you pull in the “ethers” package directly, instead of the sub-package? There are a lot of steps in producing a dist build, I wonder if one of those steps would help.

[roderik]

Does your webpack config specify the "browser" field in the mainFields? Because the URL package is not used in any of the browser versions of the web packages... It sounds like it is pulling the node version in, instead of the browser version.

This is a plain create-react-app with no access to the webpack config. We do use typescript though, so maybe that will take the node version and not the browser version.

And what if you pull in the “ethers” package directly, instead of the sub-package? There are a lot of steps in producing a dist build, I wonder if one of those steps would help.

Currently, I do not have the time to redo the implementation as I made it work and we have an urgent side project that needs completing. If you could keep this open until I can switch back that would be much appreciated. (in case nobody else has the same issue)

[ricmoo]

Sure thing. :)

[ricmoo]

Can you try the latest beta version, 5.0.0-beta.192?

I think this should be fixed along with the issue #874, if you need more details. I should have linked the fix to this issue too, but didn’t notice the relation until I was cleaning up some issues.

[roderik]

Happy camper here! Sorry for not helping out with the debugging

[ricmoo]

No worries. All that matters is we found it. :)

Not sure who to open a bug against upstream though; it’d be nice to help them fix this for future users...