Web3 Eth Personal

[nazarhussain]

Description

Add web3-eth-personal package with it's implementation.

Fixes #4720

Type of change

• New feature (non-breaking change which adds functionality)

Checklist:

• 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:unit with success.
• 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 and tested 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.

[lgtm-com]

This pull request introduces 3 alerts when merging 5f3a2b2 into 96026ec - view on LGTM.com

new alerts:

• 3 for Unused variable, import, function or class

[jdevcs]

I think web3.js shouldn't block these functions using await and it should return promise , and let user wait for promise resolution . so user code is able to leverage async based on his requirements. Same suggestion for all following functions.

[nazarhussain]

User of the library will be interacting with getAccounts function that will be returning the promise in any case. So either we return Promise chain with then block to process result or use await both have exactly same user experience.

Use will be able to leverage async behavior, no matter we use await in the function or not, because the function user is interacting with is returning the Promise. That's the fundamental of adoption of async/await pattern.

[spacesailor24]

Regarding packages/web3-eth-personal/src/index.ts, while I understand the efficiencies of a single file that includes the validation and formatting of parameters and the sending of the JSON RPC payload, this goes against the pattern that was established for the eth_ RPC methods

I still think a more versatile approach would be splitting the methods into the separate files:

• rpc_methods.ts: Bare minimum RPC methods that don't include any validation or formatting
• rpc_method_wrappers.ts: For methods that make use of validation and/or formatting
• index.ts: imports and minimally wraps methods from above two files

jdevcs is currently unavailable to dismiss stale review