Move generation into root

[willclarktech]

This PR moves the generation script into the root so the generated files can be reused across different packages. I've left the build step in the package(s). The main open question at this point is about nesting levels for exports from the published packages. For example, from the @cosmjs-types/cosmos package we have types exported from cosmos, gogoproto, google modules etc. Do we want these all at the same level as is the default output from ts-proto?

import { BaseAccount } from '@cosmjs-types/cosmos/cosmos/auth/v1beta1/auth'; // double cosmos is awkward
import { PublicKey } from '@cosmjs-types/cosmos/tendermint/crypto/keys';

Or do we want the cosmos types to be prioritised somehow?

import { BaseAccount } from '@cosmjs-types/cosmos/auth/v1beta1/auth'; // one level of nesting removed
import { PublicKey } from '@cosmjs-types/cosmos/tendermint/crypto/keys';

Or even have the others deprioritised?

import { BaseAccount } from '@cosmjs-types/cosmos/auth/v1beta1/auth';
import { PublicKey } from '@cosmjs-types/cosmos/lib/tendermint/crypto/keys'; // one level of nesting added

This is all assuming we get rid of the build level.

[webmaster128]

What I would do is spread the output from one source across different packages, e.g.

import { BaseAccount } from '@cosmjs-types/cosmos/auth/v1beta1/auth';
import { PublicKey } from '@cosmjs-types/tendermint/crypto/keys';
import { Any } from '@cosmjs-types/google/protobuf/any';

[webmaster128]

Or does this mean the cosmos types don't find their dependencies anymore because they are in different packages, e.g. https://github.com/cosmos/cosmjs/blob/main/packages/stargate/src/codec/cosmos/auth/v1beta1/auth.ts#L4

[willclarktech]

@webmaster128 Yes exactly, the plan is still to publish separate packages to the extent we need them, but everything here is necessary for the cosmos types only, and given that we encourage the use of nested path imports we have no way of stopping people from importing those other ones.

[webmaster128]

My plan was to make a direct relation between the proto namespace and the import, i.e. the package name x in @cosmjs/x is the first component of the proto namespace. This does not seem to work. So I wonder if we should publish multiple packages at all or put everything in one package like this:

                         // 👇 no @ here anymore
import { BaseAccount } from 'cosmjs-types/cosmos/auth/v1beta1/auth';
import { PublicKey } from 'cosmjs-types/tendermint/crypto/keys';
import { Any } from 'cosmjs-types/google/protobuf/any';

[willclarktech]

In that case, why not add a package to the CosmJS monorepo? @cosmjs/types?

[webmaster128]

It allows us to remove the ts-proto setup from cosmjs, avoid the re-compilation of the types and have an independent release cycle.

[webmaster128]

Nice

[webmaster128]

Does this contain all comos types? I guess we need to prepare for a multi source setup somehow.

[webmaster128]

Can we rename this folder to wasmd-0.16 and check out at v0.16.0? v0.17.0 contains some .proto changes that are compatible and for wasmd-0.18 we'll need a second source if we want to support the older networks.

[willclarktech]

This is already checked out at v0.16, but I can rename it to prepare for the multiple sources.

[willclarktech]

And yes, it contains all the cosmos types. I thought it was neat because we keep the versions in sync, but maybe that won't be sufficient once we have multiple wasmd versions.

[webmaster128]

It's a good and important start. One thing I would try next is merge cosmos-sdk-0.43 into the output and see what happens. Ideally we only see compatible overrides and additions.

[willclarktech]

OK, I'll merge this then and add that in another PR.

[webmaster128]

💪🐎