Improvements to make 4.x compatible with different projects

[nazarhussain]

While migrating truffle came across a few changes which are required to make web3@4x compatible with a lot of projects our there.

Here is the the list of individual changes:

• Need to change the TS target to ES2016 for broader compatibility
• Need to export formatters as namespace from web3-common package.
• web3.eth.net namespace is not exported
• web3.eth.personal namespace is not exported
• web3.utils namespace is not exported
• web3.modules namespace is not exported
• Web3.utils static namespace is not exported
• Web3.version static namespace is not exported
• Parameter for the web3 constructor is required, need to be optional for 1.x compatibility
• Parameter for web3.setProvider is required, need to be optional for 1.x compatibility.
• Truffle HDWalletProvider type is not assignable to SupportedProviders type.
• Would be nice to rename PromiEvent class to Web3PromiEvent to make it more compatible with 1.x implementation.
• Every provider should have have send method for backward compatibility.

[nazarhussain]

Related to remaining two points for the setting optional provider. It's causing a lot of change around different types. Once an object of any context is initialized, we expect that provider will also be initialized. So making it optional will introduce null assumptions on many places and would require refactoring quite a few types.

So I suggest to consider this a breaking change and request users to not initialize object without a provider. Hope there will not such usage around Daaps anyway.

[mpetrunic]

• Parameter for the web3 constructor is required, need to be optional for 1.x compatibility

Why not do the same thing as ethers and if not provided, init DefaultProvider (Infura/etherscan with hardcoded tokens https://github.com/ethers-io/ethers.js/blob/a71f518255/packages/providers/src.ts/infura-provider.ts#L17)?

Of course, you would need to print a warning to the console that this is not meant for production but it provides rapid way to prototype something locally without going to create infura account (which would only be something devops is doing).

[nazarhussain]

@mpetrunic I suspect people will ignore this warning and will ship their code to different environments. That will be a misuse of that Infura/Etherscan project.

Pros:

1. Use can initiate the object right away without to worry about provider
2. Easy and quick prototyping

Cons:

1. User will ignore any warning and can ship the code with our default provider
2. May provide false impressions to new users that they don’t need a provider to connect

---

As of my experience any implicit assumptions always introduce bugs and confusions for the users. So if we provide a default provider url under the hood, developers will always either confused or misuse.

On the other hand same behavior can be achieved in an explicit manner.

We can export a constant from our package DEV_INFURA_URL, And if users want to quickly prototype they can import and use it while initiating the object. This way they will be aware what’s actually happing and there are least chances they miss or misuse it.

[nikoulai]

I would agree that the cons seem important and may confuse the end-users (mostly the newcomers to web3.js and ethereum).
DEV_INFURA_URL looks like a good solution.
As an alternative, we could create a new constructor, which, uses the infura, and is explicit about that. Like new Web3.Web3WithDevProvider().

[spacesailor24]

Given that the rewrite of Web3.js is supposed to target the incoming new ETH devs, I find it risky to get users comfortable with not providing their own provider. This is especially true when you consider that a provider is how users get their information from the blockchain and users should never be okay with trusting someone else's provider (technically even in prototyping too). Understanding Web3.js is unlikely to be malicious, I don't think a default provider (with out explicit use such as DEV_INFURA_URL) is something we should continue as a practice