There are dependencies to "ethereumjs-util" and "@ethereumjs/util"

[richtera]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

Internally the code refers to ethereumjs-util but due to also using @ethereumjs/tx and @ehterumjs/common but those modules referring to ethereumjs-util by it's new name @ethereumjs/util there is some code duplication inside of packaged output which also makes it harder to properly upgrade to newer versions of crypto modules.

Expected Behavior

Ideally ethereumjs-util should no longer be used if the new naming is used for the other modules.

Steps to Reproduce

import "web3-eth-accounts"

// will cause both modules to be in the bundle because web3-eth-accounts requires `ethereumjs-util` and `@ethereumjs/tx` and 
// `@ethereumjs/common` which in turn include `@ethereumjs/util`

Web3.js Version

1.9.0

Environment

• Operating System: Ubuntu 22.10
• Browser: Chrome Version 111.0.5563.149 (Official Build) (64-bit)
• Node.js Version: v18.14.0
• NPM Version: yarn 3.3.0 npm 9.3.1
• Webpack: 5.79.0

Anything Else?

The current way to prevent upgrade problems is to leave
"ethereum-cryptography": "1.2.0",
and
"@noble/secp256k1": "1.7.1",

[paulmillr]

Why?

@ethereumjs/util is useful and well-tested. Removing its old non-namespaced variant is a goal, but not seeing why removing @ is useful?

[richtera]

The removal is not necessary except requiring one and then requiring a module that requires the other will cause both sets of routines with all their dependencies to be included in the output bundle of a web app. They cannot be tree shaken out.

[mconnelly8]

6/12 - keep

[richtera]

6/12 - keep

It was never about removing. I think it would make sense to remove the import to the non-namespaced module from the namespaces tx module and change it so it matches the name spaced one.

[mconnelly8]

Hey @richtera , my comment was about removing anything. It was a note from our team meeting reviewing v1 items to indicate if we were keeping or closing them.

We will be reviewing this, but we recommend using the full v4 release last week to get the full experience of web3.js.