Idl version

[pyramation]

when this is reviewed (and tested locally) will close https://github.com/CosmWasm/ts-codegen/issues/59

• [x] reviewed
• [x] local global CLI install test

caveat: while we now have responses, we'll add support for this in another issue and PR https://github.com/CosmWasm/ts-codegen/issues/61

@uint correct me if I'm wrong, but I don't think it breaks anything if this PR enables parsing of the new idl format to be treated like the current published version of ts-codegen (meaning w/o the named responses and keeping the <Thing>Response style for now til we close #61 )

[uint]

@uint correct me if I'm wrong, but I don't think it breaks anything if this PR enables parsing of the new idl format to be treated like the current published version of ts-codegen (meaning w/o the named responses and keeping the Response style for now til we close https://github.com/CosmWasm/ts-codegen/issues/61 )

I mean, if contract developers are willing to only partially migrate to the new way of generating APIs (while keeping the old <Thing>Response.json boilerplate), I imagine it should work out.

[uint]

This isn't a priority or anything, but in the future it would be nice to parse the idl_version as a semver value and make sure it satisfies the semver requirement of ^1.0.0 (or whatever the supported version is at the time). And just crash otherwise with IDL version {idl_version} not supported.

[pyramation]

great! thanks @uint

This isn't a priority or anything, but in the future it would be nice to parse the idl_version as a semver value and make sure it satisfies the semver requirement of ^1.0.0 (or whatever the supported version is at the time). And just crash otherwise with IDL version {idl_version} not supported.

I agree! awesome idea https://github.com/CosmWasm/ts-codegen/issues/62