Releases tracking issue

[holgerd77]

This issue tracks problems of consumers of our beta-releases libraries which we should fix.

General

• [ ] Some error messages check expected === actual but do not report what the expected and actual values are (handy for debugging)

Common

• [ ] It should be possible to query what ChainIDs we supporrt: there should be a map ChainId: number -> CustomChain so that one can query whatever custom chain is meant by what chainId and then pass this enum in the Common.custom method.
• [x] Merge total terminal difficulty is td in the lib, should be ttd #2075

EVM

• [ ] Verify that examples in README are correct
• [x] @types/async-eventemitter is listed as devDependency: this should be a dependency, otherwise consumers cannot access the on property of EVM. #2077
• [ ] Async eventemitter type when using an async function to listen to events is not right (second argument could be undefined, and the function needs an argument when called).

VM

• [x] To create EEI, one does import { EEI } from "@ethereumjs/vm"; const eei = new EEI.EEI(...);, this is ugly and it should be new EEI, probably caused by export * as EEI from './eei/eei' should probably be export * from './eei/eei' -- in process with #2078
• [x] @types/async-eventemitter is listed as devDependency: this should be a dependency, otherwise consumers cannot access the on property of VM. #2077
• [ ] When creating the VM, the evm property is cast as EVMInterface. If VM is created without injecting the EVM, it thus creates EVM, which should also be cast as such. It would also be nice that if the EVM is injected, it automatically infers the returned type (so if you create our EVM then it should also infer it as EVM)
• [x] It seems that BlockchainInterface and Blockchain type are mixed internally (it is hard to import a custom BlockchainInterface -> _init() for instance does not exist -- in process with #2069
• [x] When creating a VM and passing an @ethereumjs/evm instance as evm option, one should also ensure that the same EEI in EVM is reused when creating the VM. Otherwise, a new EEI will be created and the warm accounts and storage slots will thus never be cleared (there will most likely also problems with touched accounts, etc.). Probably, EEI should be a public property of the EVM interface, and if the EVM interface is passed as option, then take the EEI from there (and ensure no custom EEI is set, if so, then throw) -- in process with #2078
• [ ] Async eventemitter type when using an async function to listen to events is not right (second argument could be undefined, and the function needs an argument when called).

[jochem-brouwer]

Will add things reported by hardhat here as well.

[acolytec3]

When creating the VM, the evm property is cast as EVMInterface. If VM is created without injecting the EVM, it thus creates EVM, which should also be cast as such. It would also be nice that if the EVM is injected, it automatically infers the returned type (so if you create our EVM then it should also infer it as EVM)

I'm not sure if this is possible. I've been experimenting with it without much luck.

[acolytec3]

Can we officially close this now?