Attempted import error: '_base16To36' is not exported from '@ethersproject/bignumber'.

[rhlsthrm]

This error is showing up when I'm trying to build in a React project:

> react-scripts build

Creating an optimized production build...
Failed to compile.

./node_modules/@ethersproject/address/lib.esm/index.js
Attempted import error: '_base16To36' is not exported from '@ethersproject/bignumber'.

It doesn't show up if I run directly from ts-node or similar though. Also runs fine with React dev mode. However, it's blocking production deployment.

[ricmoo]

Do you use yarn? It seems to too aggressively cache things...

Can you try removing the package-lock.json, node_modules (and if you use yarn the yarn lock file) and redo npm install?

[rhlsthrm]

Just tried that, no dice :(. Using npm, not yarn. Also it's failing the same way in an AWS Amplify deployment which is building from scratch, so nothing is being cached. We are able to build with tsc no problem, it seems to be isolated to the React build scripts.

[ricmoo]

I think I found a way to solve this. I'm not sure why it is an issue, but I have some ideas. But let me get this fix out first and then I can dig into it... :)

I've made the fix locally, and it is running the build process. After than I'll push, and once the CI has completed, I'll publish the changes.

[rhlsthrm]

Thanks a bunch for the lightning-quick turnaround! Will test it on my end as soon as it's published.

[ricmoo]

Can you try out 5.0.21 and see if that fixes things?

[rhlsthrm]

That fixed the issue! Did the individual @ethersproject/address package get upgraded too? We want to use the individual packages instead of the umbrella package.

[ricmoo]

Ah, that is kinda what I suspected (or that another dependency was using it).

The problem was I made an underlying change to the imports of address (which pulled in a new export from bignumbder), but didn't bump its package.json version. That's all that was needed.

The way that ethers locks most dependency versions (for packages within its monorepo), is to use exact versions in the umbrella package.json. This means that if you install the umbrella, the latest versions (as of when that version of the umbrella was released) will be locked in, which means the package manager will get those regardless, so the additional indirect dependencies of those packages will also get those versions (this is where yarn sometimes fails to re-evaluate the minimum viable package sets).

But, for each sub-package, caret versions are specified, so that a simple change in bytes, for example, does not cascade and need every other package to get its version bumped, and therefore re-published. Otherwise, every small change would require a release of all 39 sub-packages.

I do need to ensure that when I make changes to dependent exports, that I match the version on the package that is doing the importing of that export. I've been trying to build a test harness around this case, but it's hard to get something that doesn't require an exponential number of test cases... I've got some ideas though so these will be caught during CI in the future.

Sorry if that sounds complicated, it is hard to explain in writing, without a blackboard. Hope that helps though. Feel free to ask follow-ups though. :)

I'm going to close this issue, but feel free to continue the conversation.

Thanks! :)

[rhlsthrm]

Got it, thanks for the explanation! So just to be clear, the latest version of @ethersproject/address won't have this issue, correct?

[ricmoo]

Oh yes. That is correct. There should be no issue going forward, regardless of whether you use the umbrella or the specific address package. You should be good to go. :)