I'm pretty ignorant of the mechanics of proto generation, and am not positive this is a telescope issue. I'm also working with the upcoming .46 cosmos release, which might be relevant

Basically, I have a repo (https://github.com/haveanicedavid/groups-ui) which is using a package (https://github.com/haveanicedavid/cosmos-groups-ts) generated through telescope, where I

1. pulled down the latest tagged SDK .46 release (v0.46.1)
2. copied the proto tags over from /proto in SDK to /proto in the telescope proj
3. pulled in missing proto files from the buf registry (buf export buf.build/cosmos/cosmos-sdk:$(curl -sS https://api.github.com/repos/cosmos/cosmos-sdk/commits/v0.46.1 | jq -r .sha) --output ./proto in the telescope proj)
4. ran the codegen script yarn codegen (fixing proto errors til it runs correctly) and published to NPM

With that, i've been able to generate an LCD client through the factory and successfully run queries, and the shape of response data on those queries is correct, but the casing is off because LCD / REST sends properties in snake_case. For example the GroupInfo interface:

compared to the response (totalWeight vs total_weight, created_at vs createdAt):

Again, I’m not sure this is an issue with telescope or on my end (there are a lot of moving parts), but it seems like the response data for LCD / REST is structured as snake_case: https://docs.cosmos.network/master/modules/group/#rest so presumably this could impact all LCD query clients generated with cosmos protos

cosmos/crypto/keyring/v1/record

  // Ledger item
  message Ledger {
    hd.v1.BIP44Params path = 1;
  }

+export interface Record_Ledger {}
 
-export interface Record_Ledger {
-  path: BIP44Params;
-}

messages that are successful in the API look like this, where the duration is basically a string:

{
      "type": "osmosis/lockup/lock-tokens",
      "value": {
        "owner": "osmo1g5555555555555555555555",
        "duration": "1209600000000000",
        "coins": [
          {
            "amount": "367423715380310220",
            "denom": "gamm/pool/1"
          }
        ]
      }
    }

However, the go repository refers to a google duration, which in turn looks like

{
   seconds: '1209600', // technically of type "Long"
   nanos: 0
}

the problem

The ts-proto output for MsgLockTokens.fromPartial() results in this nested property { seconds, nanos}, not the string that the API expects.

from telegram:

...can't compile my proto because Long.fromValue() in ts, it can't casting loing type in DeepPartial... Can you help me? Below is sample code.

fromPartial(object: DeepPartial<TxResponse>): TxResponse {
    // ...
    message.height = object.height !== undefined && object.height !== null ? Long.fromValue(object.height) : Long.ZERO;
    // ....
}

Error is occured in Long.fromValue(object.height) bacause it can cast only Long type but object.height is not a Long type in my environment. It is declared Long type, but in DeepPartial maybe it is not just Long type...

But it is correctly compiled with changing DeepPartial to Partial.

Bare with me as this is probably user error. I'm newish to ts projects and dependencies, so it's probably something simple. This is what I'm getting with my tsc build of a project I'm working on. I've spent quite a bit of time trying different things, including building the osmojs module in node_modules from scratch, which failed with a babel error on an 'unexpected unum'.

High level, I'm just trying to write a cli to do some swaps. I'm familiar enough with js to I think pull it off in ts, but don't know Go well enough to use the normal osmosis-sdk. If I'm headed down the wrong path I'm open to suggestions!

tsc output

node_modules/osmojs/types/proto/google/bundle.d.ts:664:53 - error TS2339: Property 'LoggingServiceV2ClientImpl' does not exist on type 'typeof import("<project-home>/node_modules/osmojs/types/proto/google/logging/v2/logging")'.

664             LoggingServiceV2ClientImpl: typeof _675.LoggingServiceV2ClientImpl;
                                                        ~~~~~~~~~~~~~~~~~~~~~~~~~~

node_modules/osmojs/types/proto/google/bundle.d.ts:724:53 - error TS2339: Property 'MetricsServiceV2ClientImpl' does not exist on type 'typeof import("<project-home>/node_modules/osmojs/types/proto/google/logging/v2/logging_metrics")'.

724             MetricsServiceV2ClientImpl: typeof _674.MetricsServiceV2ClientImpl;
                                                        ~~~~~~~~~~~~~~~~~~~~~~~~~~

node_modules/osmojs/types/proto/google/bundle.d.ts:1007:52 - error TS2339: Property 'ConfigServiceV2ClientImpl' does not exist on type 'typeof import('<project home>node_modules/osmojs/types/proto/google/logging/v2/logging_config")'.

1007             ConfigServiceV2ClientImpl: typeof _673.ConfigServiceV2ClientImpl;
                                                        ~~~~~~~~~~~~~~~~~~~~~~~~~

node_modules/osmojs/types/proto/google/bundle.d.ts:1102:43 - error TS2339: Property 'OperationsClientImpl' does not exist on type 'typeof import("<project home>/node_modules/osmojs/types/proto/google/longrunning/operations")'.

1102         OperationsClientImpl: typeof _676.OperationsClientImpl;

Applicable Code

import {
    AminoTypes,
    SigningStargateClient
} from '@cosmjs/stargate';
import { Registry } from '@cosmjs/proto-signing';
import { defaultRegistryTypes } from '@cosmjs/stargate';
import { OfflineSigner } from '@cosmjs/proto-signing'
import { osmosis } from 'osmojs';

tsconfig.json

{
  "compilerOptions": {
    "target": "es6",
    "allowJs": true,
    "noImplicitAny": false,
    "module": "commonjs",
    "sourceMap": true,
    "outDir": "out",
    "esModuleInterop": true,
    "allowSyntheticDefaultImports": true,
    "moduleResolution": "node"
  },
  "include": ["src/*.ts"],
  "exclude": ["**/node_modules", "**/.*/"],
}

package.json dependencies (some probably unecessary, but whatevs at this point)

  "dependencies": {
    "@cosmjs/launchpad": "^0.27.1",
    "@cosmjs/proto-signing": "^0.28.4",
    "@cosmjs/stargate": "^0.28.4",
    "@keplr-wallet/types": "latest",
    "axios": "latest",
    "osmojs": "^0.4.45",
    "secretjs": "latest",
    "ts-node": "^10.8.0",
    "@protobufs/osmosis": "latest"
  }

• [x] Long[]

https://github.com/pyramation/protobuf-example-reference/blob/master/ts/cosmwasm/wasm/v1/query.ts#L184 https://github.com/pyramation/protobuf-example-reference/blob/master/ts/cosmwasm/wasm/v1/query.ts#L1407-L1411

• [x] CustomType

https://github.com/pyramation/protobuf-example-reference/blob/master/ts/cosmos/tx/v1beta1/tx.ts#L1430-L1446

• [x] Enums

https://github.com/pyramation/protobuf-example-reference/blob/master/ts/cosmos/tx/v1beta1/tx.ts#L1430-L1446

First off, thank you for this impressive package!

Im busy running the transpile step on our chains protobuf files and I am getting this error above.

How would I address this ? It appears on the surface to be a support issue for the protocol buffers but I may be wrong.

Can someone add some insight here?

Error: Multiple types are registered with Amino type identifier 'cosmos-sdk/MsgVote': '/cosmos.gov.v1beta1.MsgVote', '/cosmos.group.v1.MsgVote'. Thus fromAmino cannot be performed.

This is a potential solution for calling toUtf8/JSON.stringify for the msg prop in MsgExecuteContract.

This is a generalized system, however, as we can parse the proto options [ (gogoproto.casttype) = "RawContractMessage" ]

https://github.com/CosmWasm/wasmd/blob/main/proto/cosmwasm/wasm/v1/tx.proto#L58

We can parse queries and get URLs and generate LCD client with types.

• [ ] plugin to hide/show certain modules/routes
• [ ] combine into nice API similar to secret.js does with modules:

queryClient.osmosis.numPools();
queryClient.osmosis.pool('...');

to/from amino with latest code doesn't serialize correctly — I'm testing out the latest with the prototype and getting serialization errors:

Error: Broadcasting transaction failed with code 4 (codespace: sdk). Log: signature verification failed; please verify account number (441730), sequence (133) and chain-id (osmosis-1): unauthorized
    at SigningStargateClient.broadcastTx

• [ ] determine how to properly manage the Long type when serializing

https://github.com/cosmos/groups-ui/blob/master/src/shared-state/groups-store.ts#L363

• [ ] fix type issue in comment below
• [ ] fix the interface so developer doesn't have to encode decisionPolicy field

import Long from 'long';
const {
    createGroupWithPolicy
} = cosmos.group.v1.MessageComposer.withTypeUrl;

const {
    PercentageDecisionPolicy   
} = cosmos.group.v1;

const msg = createGroupWithPolicy({
    admin: 'a string',
    groupMetadata: 'string here',
    groupPolicyAsAdmin: true,
    groupPolicyMetadata: 'a string here too',
    members: [], // MemberRequest[],
    decisionPolicy: { // types here aren't exactly happy with the encode function for some reason...
        // WE CAN IMPROVE THIS....
        typeUrl: '/cosmos.group.v1.PercentageDecisionPolicy',
        value: PercentageDecisionPolicy.encode({
            percentage: 'a string',
            windows: {
                votingPeriod: {
                    nanos: 0,
                    seconds: Long.fromValue(100)
                },
                minExecutionPeriod: {
                    nanos: 0,
                    seconds: Long.fromValue(100)
                }
            }
        }).finish()
    }
})

• [ ] #238
• [ ] #239
• [ ] #247
• [ ] #211
• [ ] #142
• [ ] https://github.com/osmosis-labs/osmojs/issues/12
• [ ] https://github.com/osmosis-labs/osmojs/issues/5
• [ ] #277
• [ ] #141
• [ ] #140
• [ ] #118
• [ ] #279
• [ ] determine if we should support durations as strings
• [ ] timestamps

currently we break in the code on Height by introspecting the props

            case 'Height': {
                // type: 'ibc.core.client.v1.Height'
                if
                    ((proto.fields.revisionNumber && proto.fields.revisionHeight) ||
                    (proto.fields.revision_number && proto.fields.revision_height)) {
                    [].push.apply(body, fromAminoMessages.height(context, name, proto));
                }
                break;
            }

• [ ] can we add a parsedType to messages, not just fields? So we can get ibc.core.client.v1.Height? (instead of looking at field names)
• [ ] clean up casing
• [ ] look at original toAmino/fromAmino (below) — do we need the omitDefault?

export const AminoConverter = {
  "/ibc.applications.transfer.v1.MsgTransfer": {
    aminoType: "cosmos-sdk/MsgTransfer",
    toAmino: ({
      sourcePort,
      sourceChannel,
      token,
      sender,
      receiver,
      timeoutHeight,
      timeoutTimestamp
    }: MsgTransfer): AminoMsgTransfer["value"] => {
      return {
        source_port: sourcePort,
        source_channel: sourceChannel,
        token: {
          denom: token.denom,
          amount: Long.fromValue(token.amount).toString()
        },
        sender,
        receiver,
        timeout_height: timeoutHeight ? {
          revision_height: omitDefault(timeoutHeight.revisionHeight)?.toString(),
          revision_number: omitDefault(timeoutHeight.revisionNumber)?.toString()
        } : {},
        timeout_timestamp: timeoutTimestamp.toString()
      };
    },
    fromAmino: ({
      source_port,
      source_channel,
      token,
      sender,
      receiver,
      timeout_height,
      timeout_timestamp
    }: AminoMsgTransfer["value"]): MsgTransfer => {
      return {
        sourcePort: source_port,
        sourceChannel: source_channel,
        token: {
          denom: token.denom,
          amount: token.amount
        },
        sender,
        receiver,
        timeoutHeight: timeout_height ? {
          revisionHeight: Long.fromString(timeout_height.revision_height || "0", true),
          revisionNumber: Long.fromString(timeout_height.revision_number || "0", true)
        } : undefined,
        timeoutTimestamp: Long.fromString(timeout_timestamp)
      };
    }
  }
};

https://twitter.com/_srph/status/1603357271328972802?s=20&t=kU9I9uRyeJKGtmnDWOOLHw

Absolutely 🔥. One suggestion: how about a step further and include an RpcProvider out of the box - call createRpcQueryHooks once and share it globally?

cc @srph