-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
Default solidity JSON ABI type not supported by Contract or Interface #602
Comments
So, it is important to note that your import from a JSON filename is not importing the value as JSON. It performs a JSON.parse, so it is actually an object. JSON is the string representation. So, if you pass in the JSON.stringify(TokenAbi), it will work fine, since it is a string, which is an allowed type. :) It’s hard to accept a generic object in a type-safe way. I’ll look into expanding the fragment types, as this was something I wrote quite a while ago when still learning TypeScript. |
Right, when I wrote JSON (fully-declared) type I was not precise, as I was trying to refer to the object type. The good part about is that, when importing a JSON file directly (with |
(oh, and yes, gas should certainly be an optional property; only Vyper and the Human-Readable ABI format have wide support for it) |
In your above example, can you try using Looking more into that, I think that may be the issue. I have confirmed in v4 that gas is not verified at the TypeScript compiler level... |
On the JSON I mentioned, there's no |
Re-reading your original comment with inspecting the source more, I think it is a bug. Looking at the Contract and Interface objects, it looks like I'm expecting an I just need to make sure this won't break anyone if I make the change, but if anyone passes in a param type, it will get cast to a fragment and fall apart in other unfortunate ways, so I think the change is safe. Testing right now... |
I've made the changes. Can you try out Thanks! :) |
4.0.41: 4.0.43: |
Yes, this is failing in our repo too: |
Oh, that is interesting... The library drops unknown types, but TS is a bit pickier, so I’ll add something for this Type. It won’t have its own fragment type in v4, but I’ll get TS to behave itself. And I’ll make sure v5 understands too. What compiler version is this? I know 0.6 has added some new types, and in need to check on what the ABI puts in place of those new pseudo-functions... |
I am using |
by the way, the rollback to include |
I think this ticket is resolved now, no? I'm going to close it, but if it is still an issue, please re-open. I've also published the fix for #721, but will leave that open a bit longer to make sure that problem is addressed too. Thanks! :) |
(also thanks for the Solidity version, I'll check out the generated ABI for that too) |
Yes, indeed the current version works for our usecase: the fallback function, of type |
Awesome! Glad to hear it. Yes, basically the ParamType is very forgiving, only requiring a "type", which is why it worked before. When I removed it, I was thinking that no one would pass in a ParamType to that function, but now I realize that people were passing things in that shared its shape. :) In v5, this is replaced by the |
I'm creating contract instances by importing the JSON ABI (out of solidity, or as copied from etherscan contract page e.g.) in typescript and passing it to the constructor, but TypeScript complains the JSON (fully-declared) type can't be assigned to
contractInterface: Array<string | ParamType> | string | Interface
.Example
Funny enough, a workaround seems to be just casting it as one of the union types, as the Interface constructor can handle the provided fragment array, but it's wrong.
The problem I see is that
ParamType[]
(the part of the union I suppose was expected to relate to this kind of use) isn't a valid ABI, as it'd represent just the type of ainput
oroutput
of either a function or event. Instead, I'd say the correct interface for the Contract constructor would be something like:This change could be reflected in the
Interface
constructor type as well.Additionally, I believe the
FunctionFragment.gas
member should be made optional (?
), as it isn't present in the JSON abi fragments.The text was updated successfully, but these errors were encountered: