Implement static type interface for Contract

[nazarhussain]

Description

Add contract static type support.

Fixes #4562

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.

[nazarhussain]

As the fixed array size is passed through the ABI as string so we need relevant map for integer values. We can set this up to maximum we want to support.

[spacesailor24]

But isn't the range X >= 0? So it's some very large number that we'd have to support up to?

[nazarhussain]

Theoretically ECMA-262 supports 2^32 -1 which is very less than what solidity supports. We can add as much number we want, but the larger numbers here will make the intelisence of TS very slow. So we have to restrict this number to some limited values.

[nazarhussain]

Added the limitation reference in the README file.

[jdevcs]

Please test type checking support for famous community contracts:
Open Zeppelin :

• ERC20,
• ERC777,
• ERC721, and

Gnosis :

• Safe / multisig

[nazarhussain]

@jdevcs I had added type tests for ERC20 and ERC721. I believe these are good enough to test the type interface for contract. Gnosis safe/multisig is splited among different contracts, if you think think that's necessary to add please share reference to its ABI to use.

[jdevcs]

@jdevcs I had added type tests for ERC20 and ERC721. I believe these are good enough to test the type interface for contract. Gnosis safe/multisig is splited among different contracts, if you think think that's necessary to add please share reference to its ABI to use.

For now just include ERC777 along with , including multisig in this PR will increase scope/time , add that in tests TODO items.

[nazarhussain]

@jdevcs Created an issue for additional type tests #4631

[spacesailor24]

Still don't fully understand all the TypeScript going on, but the tests seem to show it works as needed. I think we should find some more complex contracts to throw at this before releasing 4.x

[nazarhussain]

@spacesailor24 Already created an issue to add more complex contract types tests. #4631

[dapplion]

I would love to have extensive JSDocs here explaining the rationale of this types. For external contributors this is hard to read and comments would help a lot

[dapplion]

Are there benchmarks of the compilation cost of extensive use of Template Literal Types? Docs say:

We generally recommend that people use ahead-of-time generation for large string unions, but this is useful in smaller cases. ref

[nazarhussain]

Never found any such, but these types provides real-time developer feedback in IDE so fast enough to use.

[dapplion]

Is there any demo project I can try with this feature? Would love to see some usage guide too

[dapplion]

To better understand this PR, please correct me if I'm wrong:

• The goal of this PR is to strongly type consumers of contracts, for example DApps and test suites
• This is an alternative to Typechain but instead of doing code generation it derives the types from the JSON ABI directly on each run

[dapplion]

Very impressive use of Template Literal Types 👍 technically this is really cool