[ethers] Expose ABI in generated code
See original GitHub issueI’m using deployMockContract
from @ethereum-waffle/mock-contract and it requires an ABI for it to be called. Typechain currently doesn’t expose this but the abi constant is in the generated factory file.
Can there be a configuration option to expose the ABI?
Issue Analytics
- State:
- Created 3 years ago
- Reactions:1
- Comments:12 (7 by maintainers)
Top Results From Across the Web
[ethers] Expose ABI in generated code · Issue #344 - GitHub
I'm using deployMockContract from @ethereum-waffle/mock-contract and it requires an ABI for it to be called. Typechain currently doesn't ...
Read more >Documentation - Ethers.js
An ABI often comes from the Solidity or Vyper compiler, but you can use the Human-Readable ABI in code, which the following examples...
Read more >Contracts — ethers.io 0.0.1 documentation
The Contract API simplifies interacting with a Contract by exposing it as a normal JavaScript object as specified by the Contract ABI.
Read more >ethereum-abi-types-generator - npm
Generate types from an ethereum ABI json file. ... Contract code to an ContractContext which is exposed in where you defined the --output...
Read more >Getting started with some Ethereum concepts and interfacing ...
The only additional package we will use for now is ethers.js, ... But not every contract will have its source code exposed here....
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Yes I think the only way to make this useful is to expose it as part of the factory class (not module).
I am fine with this change. The only problem that I see is that hardhat users confuse these factories often with factories from hardhat (and we diverge these interfaces even more) but I am planning to address it in a separate ticket (https://github.com/ethereum-ts/TypeChain/issues/359).
I agree that this would be useful in some cases. I actually used to import the json files too, before the factory classes were added to the ethers target here. @krzkaczor what do you think?
How about adding the data as
abi
andbytecode
static readonly properties of the factory class? IMO it feels better than exporting very generic names likeabi
orbytecode
from each factory file.