Instantiating web3 unavoidably prints console warnings regardless of relevance

[haltman-at]

Expected behavior

Instantiating web 3 should not print warnings to the console; or at the least, it should not print warnings about parts of web3 that the user may not be using.

Actual behavior

Instantiating web3 -- with or without a provider -- prints the following warnings:

web3-shh package will be deprecated in version 1.3.5 and will no longer be supported.
web3-bzz package will be deprecated in version 1.3.5 and will no longer be supported.

This occurs regardless of whether any actual use of web3-shh or web3-bzz is made.

Relevance / context

I'm commenting here from the Truffle project; we'd been using web3 1.2.9 due to #3748, but with 1.3.4 this bug is finally fixed and so we were finally able to upgrade to 1.3. However, it turns out we've had to revert that upgrade, as using 1.3.4 means our CLI output is interrupted by large numbers of irrelevant warnings. Truffle uses neither web3-shh nor web3-bzz, but our users get warned about it anyway, and the volume of these warnings overwhelms useful output.

So, I would like this to be fixed so that we at Truffle can finally upgrade to web3 1.3, as people have been asking us to do.

Thank you!

Steps to reproduce the behavior

const Web3 = require("web3");
const web3 = new Web3();

Environment

web3.js: 1.3.4
node.js: v10.22.1

[GregTheGreek]

Interesting, so web3 auto-imports bzz and shh by default (its in the main web3 export). how bad does this look in the logs?

cc: @frankiebee any thoughts?

[sergeybarinov1]

yarn remove web3-util
yarn remove web3
yarn add web3-util@1.3.3
yarn add web3@1.3.3

gets rid of the console warnings...

[zaryab2000]

Simply re-installing the 1.3.3 version of web3 and web3-utils will eradicate these warnings.

Hope that helps

[ndorf]

The warnings can also be avoided by instantiating only the subpackages you need, not the whole Web3 metapackage. In other words, instead of

const Web3 = require('web3');

something like

const Web3Eth = require('web3-eth');
const Web3Util = require('web3-utils')

[haltman-at]

I'm aware of that, but to make that change throughout our entire codebase -- which would also require changing web3.eth.etc to web3eth.etc, and making sure we didn't also use that web3 instance for utils, so it's not as simple as purely changing the imports -- would be quite an undertaking. The point is that web3 should not be doing this, because we're using it to write a CLI application and we can't have other things printing warnings to the console in an uncontrollable manner. (Similarly, for the reasons discussed above, we cannot use Web3 1.3.3.) I am looking for this issue to actually be fixed here, because I consider it to be an actual problem.

[githubbbie]

agree

[haltman-at]

Hi, what with Berlin coming up I wanted to check on this. I'm assuming that you're planning to implement support for access lists in an upcoming version, right? (I don't see an issue for it, but I have to assume this is planned.) When this happens we'll want to upgrade Truffle to the new version so that our users can use access lists, but, again, we cannot upgrade until this bug is fixed.

Btw, one possible way to deal with this, if you insist on having some sort of console warnings for Shh and Bzz, might be to print a warning the first time a non-constructor method is called, rather than when they're created. Obviously that would be a bit tedious to code, but...

[haltman-at]

Oh, it looks like #3917 addresses this. It wasn't linked so I didn't know that was going on. OK, whew! So we should be finally able to upgrade to 1.3.5, then. :)

[petkodes]

Switching the version to ^1.3.5-rc.0 did the trick for me

[haltman-at]

I mean, yes, but I'm waiting for 1.3.5 to actually be released before upgrading! (I'm hoping that's soon? The candidate has been out nearly two weeks...)

[bigchiano]

yarn remove web3-util
yarn remove web3
yarn add web3-util@1.3.3
yarn add web3@1.3.3

gets rid of the console warnings...

This fixed the issue for me thanks

[haltman-at]

This can be closed now, right? This was fixed in 1.3.5, right?

[bigchiano]

This can be closed now, right? This was fixed in 1.3.5, right?

Well I guess so, but it works for me.

[haltman-at]

OK, I'm going to go ahead and close this, I don't know why this is still open given that this was fixed in 1.3.5 -- thanks again for that, btw!