Enable the user to use only web3 as dependency

[Muhammad-Altabba]

Description

Fixes #5508

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist for 1.x:

• I have selected the correct base branch.
• I have performed a self-review of my own code.
• I have commented my code, particularly in hard-to-understand areas.
• I have made corresponding changes to the documentation.
• My changes generate no new warnings.
• Any dependent changes have been merged and published in downstream modules.
• I ran npm run dtslint with success and extended the tests and types if necessary.
• I ran npm run test:cov and my test cases cover all the lines and branches of the added code.
• I ran npm run build with success.
• I have tested the built dist/web3.min.js in a browser.
• I have tested my code on the live network.
• I have checked the Deploy Preview and it looks correct.
• I have updated the CHANGELOG.md file in the root folder.

Checklist for 4.x:

• I have selected the correct 4.x base branch.
• Within the description, the feature or issue is discussed in detail or an issue is linked.
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas.
• I have added any required tests for the changes I made
• I have made corresponding changes to the documentation
• Any dependent changes have been merged and published in downstream modules.
• I ran yarn successfully
• I ran yarn lint successfully
• I ran yarn build:web successfully
• I ran yarn test:unit successfully
• I ran yarn test:integration successfully
• I ran compile:contracts successfully
• I have tested my code.
• I have updated the corresponding CHANGELOG.md file in the packages I have edited.

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Pages

Latest commit:	001a9bc
Status:	✅  Deploy successful!
Preview URL:	https://770a804a.web3-js-docs.pages.dev
Branch Preview URL:	https://feature-5508-use-web3-as-onl.web3-js-docs.pages.dev

View logs

[mpetrunic]

Generally looks good, I have two questions:

1- What do you think from DevEx perspective would it be better to group
ethAbi/ethIban/ethPersonal under eth namespace? Same goes for providers
So for example

import {eth} from "web3"
eth.iban.Iban()

2- Maybe export types without namespace so they are autoimported for users and so user doesn't have to do something like: export function something(): types.Web3Api?

[Muhammad-Altabba]

1- What do you think from DevEx perspective would it be better to group ethAbi/ethIban/ethPersonal under eth namespace? Same goes for providers So for example

import {eth} from "web3"
eth.iban.Iban()

Well, this is a nice suggestion. But it would bring circular dependencies. For example, currently, web3-eth-ens uses web3-eth. And to achieve the proposed situation we need to use web3-eth-ens inside web3-eth in order to export it. (We need to add web3-eth-ens to the dependencies of web3-eth and then write export * as ens from 'web3-eth-ens';).

2- Maybe export types without namespace so they are autoimported for users and so user doesn't have to do something like: export function something(): types.Web3Api?

Actually, that would bring conflicts because we have the same name for functions and objects that exist in different packages (the list of errors are here: #5508 (comment)). And renaming those functions/objects or consolidating them would be nice. But it would introduce some more breaking changes.

Or what do you think?

Thanks,

[Muhammad-Altabba]

1- What do you think from DevEx perspective would it be better to group ethAbi/ethIban/ethPersonal under eth namespace? Same goes for providers So for example

import {eth} from "web3"
eth.iban.Iban()

Well, this is a nice suggestion. But it would bring circular dependencies. For example, currently, web3-eth-ens uses web3-eth. And to achieve the proposed situation we need to use web3-eth-ens inside web3-eth in order to export it. (We need to add web3-eth-ens to the dependencies of web3-eth and then write export * as ens from 'web3-eth-ens';).

I found a way to do it without exporting the sub-packages from inside the package (no need to write export * as ens from 'web3-eth-ens'; at web3-eth. Actually, I arranged this using files inside the web3 package).
And I pushed the code.

@mpetrunic
So, is it good now? Or you would like to discuss the second point or any other?
Thanks,

[mpetrunic]

1- What do you think from DevEx perspective would it be better to group ethAbi/ethIban/ethPersonal under eth namespace? Same goes for providers So for example

import {eth} from "web3"
eth.iban.Iban()

Well, this is a nice suggestion. But it would bring circular dependencies. For example, currently, web3-eth-ens uses web3-eth. And to achieve the proposed situation we need to use web3-eth-ens inside web3-eth in order to export it. (We need to add web3-eth-ens to the dependencies of web3-eth and then write export * as ens from 'web3-eth-ens';).

I found a way to do it without exporting the sub-packages from inside the package (no need to write export * as ens from 'web3-eth-ens'; at web3-eth. Actually, I arranged this using files inside the web3 package). And I pushed the code.

@mpetrunic So, is it good now? Or you would like to discuss the second point or any other? Thanks,

Yeah! I guess only types are left, which ones are conflicting? Maybe it makes sense to rename or not export some?

[Muhammad-Altabba]

Yeah! I guess only types are left, which ones are conflicting? Maybe it makes sense to rename or not export some?

Thanks @mpetrunic, Actually, the conflicting types are listed here: #5508 (comment)
And I could go through the 19 errors. And here are their cases:

1. First case is: there are 2 methods that has the same name but with different implementation. This is for sign and signTransaction functions that exist in:

   web3.js/packages/web3-eth/src/rpc_method_wrappers.ts

   Line 1459 in 4bbc030

   export async function sign<ReturnFormat extends DataFormat>(

   
   And in:
   

   web3.js/packages/web3-eth-accounts/src/account.ts

   Line 134 in 0727f26

   export const sign = (data: string, privateKey: Bytes): SignResult => {

   
   Hotwever, just to take a look. There is also sign and signTransaction exported from web3-rpc-methods. But it is exported inside personalRpcMethods in:

   web3.js/packages/web3-rpc-methods/src/personal_rpc_methods.ts

   Line 85 in 4bbc030

   export const sign = async (

Suggestion: rename the sign at web3-eth-accounts to be signWithPrivateKey. And signTransaction to be signTransactionWithPrivateKey.

---

2. The other case is for a class and an interface given the same name like for Web3Error:
   

   web3.js/packages/web3-types/src/error_types.ts

   Line 18 in b766282

   export interface Web3Error extends Error {

   
   And
   

   web3.js/packages/web3-errors/src/web3_error_base.ts

   Line 22 in b766282

   export abstract class Web3Error extends Error implements ErrorInterface {

   
   Similar case is for Web3DeferredPromise that its interface is defined in web3-types and its class is defined in web3-utils. But both have the same name.

Suggestion: Rename such interfaces to be ObjectInterface and leave the class as is.

---

3. The third case is for AbiInput and AbiParameter that has duplicate definitions in:
   

   web3.js/packages/web3-types/src/eth_types.ts

   Line 226 in b766282

   export type AbiInput = {

   
   And in:
   

   web3.js/packages/web3-eth-abi/src/types.ts

   Line 87 in 3f72f52

   export type AbiInput = string | AbiParameter | { readonly [key: string]: unknown };

   
   Additionally, TypedArray is duplicated in web3-utils and web3-validator.

Suggestion: Move all types from /packages/web3-eth-abi/src/types.ts to web3-types package as we did this for similar cases. However, the definitions are not identical and so there will be a need to investigate and then consolidate them.

---

4. The forth case is for checkAddressCheckSum, isAddress, isBloom, isContractAddressInBloom, isHex, isHexStrict, isInBloom, isNullish, isTopic, isTopicInBloom and isUserEthereumAddressInBloom. Which are exported at web3-utils and then re-exported at web3-validator.

Suggestion: Move all those to web3-types package.
[UPDATE] Suggestion: export at web3-utils inside a namespace.

---

5. The last case is for LogsSubscription that exists in both web3-eth (similar to the first case):
   

   web3.js/packages/web3-eth/src/web3_subscriptions.ts

   Line 11 in e5f76aa

   export class LogsSubscription extends Web3Subscription<

   
   And in web3-eth-contracts:
   

   web3.js/packages/web3-eth-contract/src/log_subscription.ts

   Line 7 in e6d4b23

   export class LogsSubscription extends Web3Subscription<

Suggestion: Actually, the two classes refer to two different things. And so, I would rename them to something like: BlocksLogsSubscription and ContractsLogsSubscription.

---

I will start appling the mentioned suggestions. However, please, let me know if you have any concern or suggestion.

Thanks,

[mpetrunic]

Few things,
exporting many methods with different names could be confusing to developers, maybe creating more namespaces could be helpful or not exporting some stuff like why would a developer need Web3Error abstract class?

The second thing, I noticed is that every package has indexed with exports like export * from "./somefile", I think it's a bad practice because:

• if you are exporting everything from every file, every change is gonna be breaking change - maybe consider exporting only stuff that developers or you actually need
• if the developer is searching for the source code of some imported class, it's gonna be a nightmare because it could be in any of these files so you can't just ctrl+click to dig through source code

[Muhammad-Altabba]

Thanks @mpetrunic ,

Few things, exporting many methods with different names could be confusing to developers, maybe creating more namespaces could be helpful or not exporting some stuff like why would a developer need Web3Error abstract class?

Regarding the first suggestion that is "maybe creating more namespaces could be helpful". I think it is the better approach. And thinking about it. Let us apply the same thing to our exported objects at the web3 package. i.e we should not have flat exports at web3 like export * from 'web3-utils'; but have export * as utils from 'web3-utils';. Do you agree with this?

For the second point "not exporting some stuff". I agree that if there is something very local and not good to export we are better to keep it local. However, for the Web3Error abstract class specifically, this class is already used in another package. Moreover, we do not know if some users would need to implement it, especially that now we support plugins :)

The second thing, I noticed is that every package has indexed with exports like export * from "./somefile", I think it's a bad practice because:

• if you are exporting everything from every file, every change is gonna be breaking change - maybe consider exporting only stuff that developers or you actually need
• if the developer is searching for the source code of some imported class, it's gonna be a nightmare because it could be in any of these files so you can't just ctrl+click to dig through source code

I created an issue for this suggestion and I hope to discuss it after finishing the current one :)

[jdevcs]

@Muhammad-Altabba good work, Over all this PR LGTM. I just added few points + there are file conflicts to check.

[github-actions]

Bundle Stats

Hey there, this message comes from a github action that helps you and reviewers to understand how these changes affect the size of this project's bundle.

As this PR is updated, I'll keep you updated on how the bundle size is impacted.

Total

Asset	Old size	New size	Diff	Diff %
Total	1.18 MB	1.06 MB	-121 KB	-10.02%

View detailed bundle breakdown

Added

Asset	Old size	New size	Diff	Diff %
../lib/eth.exports.d.ts.map	0	358 bytes	358 bytes	-
../lib/eth.exports.d.ts	0	321 bytes	321 bytes	-
../lib/providers.exports.d.ts.map	0	292 bytes	292 bytes	-
../lib/providers.exports.d.ts	0	238 bytes	238 bytes	-

Removed

No assets were removed

Bigger

Asset	Old size	New size	Diff	Diff %
../lib/index.d.ts	77 bytes	899 bytes	822 bytes	1067.53%
../lib/index.d.ts.map	155 bytes	919 bytes	764 bytes	492.90%

Smaller

Asset	Old size	New size	Diff	Diff %
web3.min.js	1.17 MB	1.04 MB	-123 KB	-10.34%

Unchanged

Asset	Old size	New size	Diff	Diff %
../lib/accounts.d.ts	3.42 KB	3.42 KB	0	0.00%
../lib/types.d.ts	1.92 KB	1.92 KB	0	0.00%
../lib/types.d.ts.map	1.75 KB	1.75 KB	0	0.00%
../lib/abi.d.ts	1020 bytes	999 bytes	-18 bytes	-1.77%
../lib/web3.d.ts	842 bytes	842 bytes	0	0.00%
../lib/web3.d.ts.map	693 bytes	694 bytes	1 bytes	0.14%
../lib/accounts.d.ts.map	528 bytes	528 bytes	0	0.00%
../lib/version.d.ts.map	140 bytes	140 bytes	0	0.00%
../lib/abi.d.ts.map	124 bytes	124 bytes	0	0.00%
../lib/version.d.ts	97 bytes	97 bytes	0	0.00%