Publish cosmos generated types in a separate package

[amaury1093]

So that it can be reused separately.

[amaury1093]

Proposal 1: Regen-centric approach

My initial idea was to create a @regennetwork/proto package, and put all ts-proto generated files inside that.

import {...} from '@regennetwork/proto/cosmos/bank/v1beta1/query';
import {...} from '@regennetwork/proto/regen/data/v1beta1/tx';

This might be the most intuitive solution, as users would only ever need to import from one package (@regennetwork/proto)

Proposal 2: Cosmos-centric approach

Export cosmos and regen types in separate packages

import {...} from '@regennetwork/proto-cosmos/bank/v1beta1/query';
import {...} from '@regennetwork/proto-regen/data/v1beta1/tx';

This is slightly more clunky, as there are two packages to import from. Users need to know which modules are in which package. But also a better separation of concerns, and other people in the cosmos community can use @regennetwork/proto-cosmos.

Proposal 3: A ts-proto community approach

ref: stephenh/ts-proto#58. Create a @ts-proto npm namespace, and put each projects (even not Cosmos/Regen-related projects) unders their own package.

import {...} from '@ts-proto/cosmos/bank/v1beta1/query';
import {...} from '@ts-proto/regen/data/v1beta1/tx';
import {...} from '@ts-proto/google/protobuf/any';

Same as above regarding 2 packages. However, it's scalable, and dependencies (such as gogoproto, confio...) are explicit in package.json.

[amaury1093]

In #7, I'm going with proposal 2. LMK if that sounds good to you.

[aaronc]

I agree with approach (2). We should put cosmos types under the @cosmos npm namespace. I can ask ICF to setup a repo for us. Wdyt?

[amaury1093]

@cosmos npm namespace

That'd be really nice, but it seems taken https://www.npmjs.com/org/cosmos

[chris-chapin]

Hi Amaury and Aaron.

I would like to contribute to the Regen Network Frontend. I assume this is the right repo and not regen-app. Is there any issue that would be a good one to get started with?

Thanks,
Chris

[amaury1093]

Hey @chris-chapin, thanks for your interest. In the next 2 weeks I'll publish a 1st version of @regen-network/api, which should at least give something working. I'll also create some self-contained issues that external contributors can pick up.

For now, I think it's still a bit early, as there are a couple of design issues I'd like to work on first. You can watch this repo for updates!

[amaury1093]

I recommend to put this on-ice, pending on cosmos/cosmjs#586. If cosmjs doesn't go with ts-proto, it's not worth to publish these types under an official cosmos org.

[gotjoshua]

pending on cosmos/cosmjs#586.

Looks like going with ts-proto is quite decided
and well on the way to implementation.
So I propose to take it off ice.

I am also ready to think along and implement some of this.

I have most resonance for option 3 above.
but then i have a question about long term maintenance.

However, if the repo is 90-100% automated with CI, it would be wicked.
If all projects in the namespace use: Buf Schema Registry (as both cosmos sdk and regen plan to), then we could architect a fully automated system that maps various repos to subfolders in the @ts-proto namespace and auto-builds on any release tags (or even on any branch pushes for that matter)

@AmauryM asked me to tag y'all:
@blushi , @haveanicedavid and @mhagel
cheers

[robert-zaremba]

BSR is a way to go. We want to use it in SDK. We definitely need:

• versioning
• create open dapp design space: enable dapps to integrate with multiple chains (not only Regen Ledger), and have a clear way to source proto files.

I'm curious if there is an implementation of that idea for NPM / Yarn registry.

If not then the Option 3 is the closest one.

[gotjoshua]

BSR is a way to go.

yes but BSR will provide the protofiles, not the ts files...
we need a solid "bridge" to publish the relevant changes in
protofiles into dev-friendly version matching packages.

[aaronc]

BSR also makes generation easy with plugins and templates

[amaury1093]

Small note: FYI there are some talks about a dynamic CosmJS client cosmos/cosmjs#885, but I don't think that should be the way to go for regen-js, so I still approve the above ideas of generating .ts files using Buf (which seems to be happening in #29 🎉), and publishing them into separate npm packages.

BSR also makes generation easy with plugins and templates

I think an automatic publishing of npm packages directly from a buf plugin will however be hard, because of amino, and some manual hardcoded stuff needs to be done, like here.

I still would root for a cosmos-centric approach (2 in the initial post), something in the vein of:

// Inside package `@regennetwork/api`;

import { ecocredits } from '@regenetwork/ecocredits'; // Generated and published by buf, thou
import { data } from '@regenetwork/data'; // idem
import { bank } from '@cosmos-sdk/bank'; // idem
import { staking } from '@cosmos-sdk/staking'; // idem

import { gluecode } from '@regennetwork/gluecode'; // Find better name than "gluecode". Basically, handles non-module client code, like RPC, signing etc... can be mostly based on CosmJS components

export const Api = gluecode([
  ecocredits(), data(), bank(), staking(), // add all necessary modules
]);
// There needs to be some advanced TypeScript magic, so that the Api object is correctly typed, e.g. `api.query.ecoc<tab>` autocompletes.

in which case other chains could re-use this gluecode easily:

// Inside package `@osmosis/api`;

// -- snip --
import { superfluid } from '@osmosis/superfluid'; // also generated by buf

export const Api = gludecode([bank(), superfluid(), ...]);

[amaury1093]

I recently discovered https://github.com/osmosis-labs/telescope, so pasting it here in case it's not under your radar. It's a Protobuf->Typescript code generator. Seems like they generate akashjs, osmojs, stargazejs etc. which was the idea of this issue.

(note that they unfortunately don't use protoc, so I'm not sure how it'll play with buf).

[haveanicedavid]

Hey @AmauryM - I’m actually playing with telescope for the cosmos groups-UI work. FYI, when you run telescope install, regen is actually an option for the presets… not sure if it’s up to date (imagine not) but should be pretty easy to try out.

It’s been a fairly smooth experience for me so far, and the creator (Dan) is really helpful

[ryanchristo]

Closing as a result of #68. We have decided to go with telescope. A new release branch was created release/v0.x if we need continued maintenance of the existing api package currently being used by regen-web.