-
Notifications
You must be signed in to change notification settings - Fork 361
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add ethers v5 target #250
Add ethers v5 target #250
Conversation
I tried this PR on a repo where I have many tests I migrated from ethers-v4 to ethers-v5 using waffle-v3 and worked for me. |
.gitignore
Outdated
@@ -14,3 +14,4 @@ examples/truffle-v4/types | |||
examples/truffle-v4/migrations | |||
examples/truffle-v5/types | |||
examples/truffle-v5/migrations | |||
.DS_Store |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this should go to your global gitignore file. otherwise we will end up with huge list of unrelevant OS files in this file.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That makes sense. Removing this from gitignore file right away.
This looks great @zemse! Thanks! I guess more tests would be nice (in a separate directory as we do for other targets). |
export function codegenAbstractContractFactory(contract: Contract, abi: any): string { | ||
return ` | ||
import { Contract, Signer } from "ethers"; | ||
import { Provider } from "ethers/providers"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@krzkaczor is this ok, or it should be import { Provider } from '@ethersproject/providers';
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
uhh good call. That's why we need tests + isolated example to catch such problems 😆
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh my bad.. fixing this for now. @krzkaczor I'll have a look at how other tests are written and add the same for v5 here.
@zemse awesome work! Yeah I would like to hear some feedback from the users. Tests would also be great! We can't publish an official release without them.
I think it's possible to implement it by using function overloads where first arg type would be string literal |
Okay, it's possible then I'll give it a try because it'd be nice to have this too. |
I'll take a look tomorrow! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've reviewed a diff between this and the v4
target package, code looks good!
Just a nitpick plus a few questions, since I didn't try ethers v5 myself yet.
export interface GenerateFunctionOptions { | ||
returnResultObject?: boolean | ||
isStaticCall?: boolean | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd move this interface to the functions.ts
file, since it's only used there and doesn't have to be exported. (this file's name types.ts
refers to handling code generation for solidity types, not TS types for this package ;) )
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very much thanks for the review. This makes sense and I'll make this change.
if (allFunctions.match(/\W Overrides(\W|$)/)) contractImports.push('Overrides') | ||
if (allFunctions.match(/\WPayableOverrides(\W|$)/)) contractImports.push('PayableOverrides') | ||
if (allFunctions.match(/\WCallOverrides(\W|$)/)) contractImports.push('CallOverrides') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why is the first regex different than the 2nd & 3rd one? (space between \W
and the name)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe is it worth extracting a helper fn to increase readability and avoid typos in the regexes? like
function pushImportIfUsed(importName: string, generatedCode: string, importArray: string[]): void {
if (new RegExp(`\\W${importName}(\\W|$)`).test(generatedCode)) importArray.push(importName);
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was afraid that /\WOverrides(\W|$)/
would match PayableOverrides
and CallOverrides
too when it shouldn't and should only match Overrides
. Is there a better way to do the same? I think would face the same issue having this as a method as the pushImportIfUsed
example
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've noticed that problem when I wrote those regexes in the ethers-v4
target :) \W
means a non-word character, and it's there specifically so \Wxyz
doesn't match abcxyz
, so it's safe to drop the extra space.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Example: https://regex101.com/r/r6Cjn4/1
? `${constructorArgNamesWithoutOverrides}, overrides || {}` | ||
: 'overrides || {}' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
does the ContractFactory
require passing empty overrides in v5, since you added the explicit || {}
here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When we don't pass any override using typechain's overrides, the overrides
is set as undefined
. But it looks like ethers v4 was fine with undefined overrides
value but in v5 it throws an error. We can make it not pass an undefined override (+1 or 2 lines) or just fall-backing to an empty override as done corrently. Is it good doing like this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is weird, not passing an optional argument should be handled exactly the same as explicitly passing undefined
there. TBH, if passing undefined
overrides throws in ethers v5, it's likely a bug there. We can leave the explicit empty overrides for now.
Thanks for pointers. I've tried to add that. I've updated the tests for ethers v5. Please have a look and let me know for any changes required. |
Thanks for all your hard work! It's moved to internal branch |
It's published as I added an example to my branch and it seems like everything works fine 👍 |
@krzkaczor Thanks for moving it forward! I'm very happy I gave this a shot, this was my first PR in OSS. I have marked the demo published package as deprecated. Let me know if I need to do anything more. BTW saw the typedAssert while writing tests, It might be common for rest of you guys but for someone like me without a programing background and barely over 1 year exp, honestly I'm was impressed with the cool stuff that I saw in this repo. One more thing which were exiting for me were the reviews (thanks to everyone for taking time to review the work and guiding me). Sorry if I sound too crazy, but I'm happy that I'm on GitHub, I have access to so many amazing people all around the world. I observed that in preparing PRs on GitHub, we get to learn a lot of best practices since we get to see a lot. So I believe I'll find more opportunities to do. Hopefully, I'll get to see you all again. |
@zemse thank you for your time putting this code together. This PR is super useful for all us using Typechain and Ethers. |
Hi @HenryNguyen5, I just encountered a problem with |
@zemse wow great work! Especially that it was your first PR to OSS. I gotta admit that TypeChain is not the easiest project to contribute to, so you should be proud of yourself even more ;) |
This PR adds a
target-ethers-v5
toTypeChain
packages and intends to close #205.Thanks to @krzkaczor and @quezak for v4 target. The v5 target in this PR builds on top of it to update the types changed in ethers v5.
To try it: by cloning repository:
git clone [email protected]:zemse/TypeChain.git
orgit clone https://github.com/zemse/TypeChain.git
cd TypeChain
yarn
(you need yarn installed if you don't)yarn build
(this generates dist dir which is imp)typechain --target ../TypeChain/packages/target-ethers-v5/
(Docs)Just in case if it's too much, I have temporarily published it to npm for testing:
npm install typechain-target-ethers-v5 --save-dev
(later you can just replace the package with official one)typechain --target ethers-v5
(Docs)Useage
Please have a look at this if it is fine and let me know of any change I need to make.