Upgrade cosmjs-types to 0.6 🔭

[webmaster128]

With this upgrade, CosmJS will use types generated by telescope 💪

[pyramation]

🎉🎉🎉

very stoked for this!

🙌🏻⚛️

[loredanacirstea]

@cosmjs/proto-signing: Remove fromJSON/toJSON from TsProtoGeneratedType such that generated types are not required to generate those anymore. The methods were provided by ts-proto but we never needed them.

We are currently using fromJSON to dynamically generate cosmos messages & queries from JSON, in our flexible web&mobile wallet for developers (ganas).

@webmaster128 was this functionality replaced by something else that I can use for dynamic JSON messages?

[webmaster128]

We are currently using fromJSON to dynamically generate cosmos messages & queries from JSON, in our flexible web&mobile wallet for developers (ganas).

Thank you for bringing this up. The main issue with the old/current fromJSON/toJSON implementations is they are not standardized at all. They do not match the Cosmos SDK JSON representations and as far as I can tell are not greatly following the proto3 JSON convention (but I could be wrong here). So I wonder how useful they can be. Would love to learn more about your use case.

[loredanacirstea]

@webmaster128

The main purpose of the wallet is to be very flexible, so devs can test/use anything. A demo is:
https://www.youtube.com/watch?v=a8uubl-UelQ&list=PL323JufuD9JCJy4i21fUatsDxAP8fENuK&index=2&ab_channel=LoredanaCirstea
I pinged you in CosmWasm Discord #cosmjs with more details.

[pyramation]

is there a reason not to use fromPartial?

Also, there is a potentially to use telescope and compile your own library. In this case you could also access more features that can cater to your application. We've made toJSON and fromJSON config options as we generally don't use them and they're non-standard, but we did keep them if you compile your own, and I'm happy to help!

I'd suggest keeping cosmjs lean, documenting proper usage. For folks that have specific needs, I'm happy to make options in telescope, and transpiler options to cover all their cases.

[webmaster128]

is there a reason not to use fromPartial?

For using fromPartial you need a data exporter first. fromPartial expects JavaScript objects such as Long, BigInt, Timestamp, Duration which do not have direct JSON representations or expose private fields when doing a naive recursive JSON.stringify on the exports.

I think having some JSON import/export is useful, but currently it is underspecified how this JSON is supposed to be structured. The reason for starting #1083 was exactly this: The JSON we get from Cosmos SDK is not a different one than what Type.fromJSON understands.

[webmaster128]

what about this: we bring toJSON/fromJSON back to the cosmjs-types build to have a safe and simple baseline set of types. Then we create cosmjs-types-slim to only include the things CosmJS needs internally for signing. This can then (a) have way less types and (b) use a minimal code generation configuration. Then project will either use:

• cosmjs-types-slim + cosmjs-types, or
• cosmjs-types-slim + custom telescope output

[webmaster128]

Also note, the diff in this PR means toJSON/fromJSON is not required anymore because we don't need them internally. The type generator is still free to have them.

[pyramation]

what about this: we bring toJSON/fromJSON back to the cosmjs-types build to have a safe and simple baseline set of types. Then we create cosmjs-types-slim to only include the things CosmJS needs internally for signing. This can then (a) have way less types and (b) use a minimal code generation configuration. Then project will either use:

• cosmjs-types-slim + cosmjs-types, or
• cosmjs-types-slim + custom telescope output

I'm all on board! This would help us implement cosmjs on osmosis since it can help us start chipping away at bundle size (cc @jonator)

also @webmaster128 — should we create a discussion somewhere we can chat about the future "slim" versions? I'm also anticipating the new recursive toAmino and fromAmino and don't want to clog this thread, but have some thoughts on how we could structure some of the packages with the goal of

1. keep an existing cosmjs which has all current functionality in place, everything should work same w/o breaking changes
2. start branching into a new slim version, which has no types (including a stargate and proto-signing packages that don't require cosmjs-types)
3. finally, a last level optimization, potentially creating a stargate-slim, that doesn't require anything except TxRaw or the bare minimum to sign transactions. Anything else can be deferred to higher-level telescope transpilation (queries, balances, staking, amino encoders)

I think we have something like this right now

├── cosmjs
    ├── @cosmjs/proto-signing
    │   └── cosmjs-types
    └── @cosmjs/stargate
        └── cosmjs-types

Maybe if we can somehow provide it to proto-signing, or would we need to make a proto-signing-slim?

├── cosmjs
    ├── cosmjs-types
    ├── @cosmjs/proto-signing (cosmjs-types provided)
    └── @cosmjs/stargate (cosmjs-types provided)

which could then enable something like

 └── cosmjs-slim
    ├── cosmjs-types-slim
    ├── @cosmjs/proto-signing
    └── @cosmjs/stargate

[webmaster128]

For now I'll turn back on the JSON function in cosmjs-types 0.6.1. It's better than nothing and some sort of JSON import/export makes sense to provide.

Regarding the bundle size, I think some serious insights are needed first. Since cosmjs-types does not use a central entry point, I'd be surprised if more code than necessary is actually bundled. The number npm shows there includes stuff like source maps, TS type definitions and JavaScript comments that certainly don't make it into the app. Looking at #904, the types are probably not our main concern wrt. size.