You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+69-6
Original file line number
Diff line number
Diff line change
@@ -34,18 +34,19 @@ A CLI tool which allows you to convert an ABI json file into fully loaded interf
34
34
- Web3 1.x and 2.x
35
35
- Ethers 5.x
36
36
- Ethers 4.x
37
+
- Hardhat
37
38
38
39
## ethereum-abi-types-generator vs TypeChain
39
40
40
41
The first question I normally get is “have you seen TypeChain”, yes I have of course and it is a great tool but it was missing and did a few things which I didn't want as a developer. The main differences with this ethereum-abi-types-generator vs typechain are:
41
42
42
43
### No bundle size at all added
43
44
44
-
With TypeChain you have a class factory you have to connect to adding size into the final bundle. This package is all interfaces meaning nothing is added to your final bundle size.
45
+
With TypeChain you have a class factory you have to connect to adding size into the final bundle. This package is all interfaces meaning nothing is added to your final bundle size.
45
46
46
47
### Exposes proper typed interfaces meaning you can use them in your application
47
48
48
-
TypeChain has dynamic interfaces aka ```public contractCall(): Promise<{ foo: BigNumber }>``` so if you wanted to use that interface somewhere in your app its not exported so can not be used. This lib generates response interfaces which are exported aka:
49
+
TypeChain has dynamic interfaces aka `public contractCall(): Promise<{ foo: BigNumber }>` so if you wanted to use that interface somewhere in your app its not exported so can not be used. This lib generates response interfaces which are exported aka:
If you have worked with dynamic interfaces you understand the pain it brings having to recreate everytime.
70
+
If you have worked with dynamic interfaces you understand the pain it brings having to recreate everytime.
70
71
71
72
### Use your provider interface your use too
72
73
73
-
TypeChain you have to connect to the factory then use the contract that way. With this lib you just use web3 or ethers interface for every contract call meaning you don't have to get use to another process it just works and zero code changes just cast and you got compile time errors for contracts.
74
-
74
+
TypeChain you have to connect to the factory then use the contract that way. With this lib you just use web3 or ethers interface for every contract call meaning you don't have to get use to another process it just works and zero code changes just cast and you got compile time errors for contracts.
75
+
75
76
## Motivation
76
77
77
78
Blockchain development in JavaScript is already super hard. You have all these tools like `truffle,``ethers`, `web3` (the list goes on) which you have to get use to and the learning curve is already quite high. On top of this, you have loads of other tools to get things to work as you need. TypeScript allows you to bring runtime errors in the compiler but on contract calls most developers have to either build their own types meaning maintaining them and easily getting out of sync or have no compile type errors using the dreaded `any` hoping and praying you don't break anything. The idea was to not have to make the developer wrap any kind of `web3` or `ethers` instance or use a new tool to get this working but with a simple 1 line change you can use all the same libraries interfaces as what the developer is use to but with `types``auto-generated` for you to bring back compile-time errors on any contract calls with super ease.
@@ -100,6 +101,8 @@ If you get compile time errors due to it waiting `web3` dependencies when using
We suggest running these within the `script` commands in npm or yarn this way you will not lose your commands and can be run on build agents as well. Also you will not get confused with sharing the script and others running in the wrong paths. Examples below:
123
132
124
133
```json
@@ -142,7 +151,8 @@ We suggest running these within the `script` commands in npm or yarn this way yo
"ethers-v5-uniswap": "npm run ethers-token-abi && npm run ethers-uniswap-exchange-abi && npm run ethers-uniswap-factory-abi"
154
+
"ethers-v5-uniswap": "npm run ethers-token-abi && npm run ethers-uniswap-exchange-abi && npm run ethers-uniswap-factory-abi",
155
+
"hardhat-example": "abi-types-generator hardhat"
146
156
}
147
157
}
148
158
```
@@ -275,6 +285,59 @@ We use `prettier` to format all files, to make sure it matches your coding style
275
285
276
286
Right now the package does not try to find any of your `tslint.json` settings. It will support this soon. For now if you get any `tslint` errors when running the linter it's best to ignore any generated file in the `linterOptions` > `exclude` of the `tslint.json`. I tend to put all my generated files in 1 place so I can ignore the entire folder.
277
287
288
+
### Using with hardhat
289
+
290
+
First you create a script in your `package.json` that runs the `abi-types-generator` script after it compiles everytime.
You types are now created within the root of your hardhat project in a folder called `ethereum-abi-types` and you can use them throughout your tests/scripts or anything `ts` related.
'can not find the artifacts > contracts directory please make sure you run this command on the route of the project and have compiled your smart contracts'
0 commit comments