Default solidity JSON ABI type not supported by Contract or Interface

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

import TokenAbi from './contracts/Token.json';
const contract = new Contract(tokenAddress, TokenAbi, signer);

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 a input or output of either a function or event. Instead, I’d say the correct interface for the Contract constructor would be something like:

contractInterface: Array<string> | Array<FunctionFragment | EventFragment> | string | Interface

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.

[ricmoo]

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…

[andrevmatos]

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 resolveJsonModule: true in tsconfig), TypeScript actually does a pretty good job in infering the resulting object’s schema/type. So it wouldn’t be a generic object, but instead a complete schema which can be made compatible with your current fragments with the types I mentioned, which could help on this. Doing a stringify would actually be more or less the same as casting it to the one of the supported types, as Interface’s constructor would immediatelly parse it back and proceed as with the casted object. Fortunately, the Fragments types are already close enough (minus only that gas member) to the parsed ABI type, so it should be feasible to have proper typing for this usecase. Thank you very much for your awesome work on this. It’s a true pleasure to work with this library on https://github.com/raiden-network/light-client =)