Fix ethers-v5 code-generation for no-argument events

[dwardu]

No description provided.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 680cef3

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[quezak]

LGTM, thanks!
Does this fix #321 (comment) ?

[krzkaczor]

CC: @zemse

[dwardu]

@quezak The code introduced in #321 generates bad code for events that have 0 arguments. I think the comment you pointed to is different, because the Transfer event being discussed there has 3 arguments.

The way the “output type” is being generated is by calling generateOutputTypes (which calls generateOutputComplexType) , which returns “complex output types” like '[boolean, BigNumber] & {value1: boolean,value2: BigNumber }'… and then taking this string and replacing & with , to produce the type-parametrization necessary for TypedEventFilter<EventArgsArray, EventArgsObject>. It’s a bit hacky, and the hack doesn't work for 0-arg events, because internally generateOutputComplexType generates the 2nd output-type only for 1+ outputs.

My fix is to, for the 0-arg event case, avoid the “hack” and use '[], {}' as the “output type” directly.

[quezak]

@quezak The code introduced in #321 generates bad code for events that have 0 arguments. I think the comment you pointed to is different, because the Transfer event being discussed there has 3 arguments.

The way the “output type” is being generated is by calling generateOutputTypes (which calls generateOutputComplexType) , which returns “complex output types” like '[boolean, BigNumber] & {value1: boolean,value2: BigNumber }'… and then taking this string and replacing & with , to produce the type-parametrization necessary for TypedEventFilter<EventArgsArray, EventArgsObject>. It’s a bit hacky, and the hack doesn't work for 0-arg events, because internally generateOutputComplexType generates the 2nd output-type only for 1+ outputs.

My fix is to, for the 0-arg event case, avoid the “hack” and use '[], {}' as the “output type” directly.

OK, thanks for the explanation -- I wanted to confirm if this solves that linked case too.
Thanks for the PR!

[dwardu]

You’re welcome @quezak. Thank you. TypeChain is a great tool, and I am happy to contribute this tiny fix.

[krzkaczor]

Thanks @dwardu! This looks good. I just want to hear @zemse's opinion on this before merging.

I will make sure to release this ASAP as it seems like an urgent fix.

[zemse]

Thanks @dwardu for the fix! I regret that this error was introduced due to the previous PR and sorry for the inconvenience in your live projects. Since the generateOutputTypes generates the 2nd output-type only for 1+ outputs, the case for 0 outputs was needed to be handled, which this PR takes care of. 👍

[dwardu]

Hi @zemse, no problem at all!, and thanks for programming the events support in the first place.

[krzkaczor]

Thanks for the fix. Released as: https://github.com/ethereum-ts/TypeChain/releases/tag/%40typechain/ethers-v5%406.0.1

[dwardu]

That’s great. Thanks 🎉