Awesome

Telescope 🔭

Telescope serves as the TypeScript Companion for CosmJS, used to generate developer-friendly TypeScript libraries for Cosmos blockchains. As a TypeScript transpiler for Cosmos Protobufs, akin to a "babel for the Cosmos", simply point to your protobuffer files and create full-typed libraries for teams to build dApps on your blockchain.

The following blockchain libraries (generated by Telescope) are available via npm

• osmojs
• dydx
• stargazejs
• juno-network
• stridejs
• injectivejs
• quicksilverjs

🎥 Checkout our video course to learn how to use telescope!

Table of contents

• Telescope 🔭
  • Table of contents
  • Quickstart
    • Generate
    • Add Protobufs
    • Transpile
    • Transpile with CLI
    • Build
    • Publishing
• Usage
  • Programatic Usage
  • Options
    • Amino Encoding
    • Implemented Interface Options
    • Prototypes Options
    • Prototypes Methods
    • Enums Options
    • LCD Client Options
    • RPC Client Options
    • Helper Functions
    • Stargate Client Options
    • State Management
      • React Query
      • Mobx
      • Pinia
    • Typings and Formating
    • Protobuf parser
    • Typescript Disabling
    • ESLint Disabling
    • Bundle
    • Output
  • Types
    • Timestamp
    • Duration
  • Composing Messages
  • Calculating Fees
  • Stargate Clients
  • Creating Signers
    • Amino Signer
    • Proto Signer
  • Broadcasting messages
  • LCD Clients
  • LCD Clients Classes
  • RPC Clients
    • Tendermint Client
    • gRPC-web Client
    • gRPC-gateway Client
  • RPC Client Classes
  • Instant RPC Methods
  • Manually registering types
  • JSON Patch Protos
  • CosmWasm
  • Helper Functions Configuration
    • Pattern Matching Priority:
    • Generated Output Examples:
    • Notes:
  • Dependencies
  • Troubleshooting
    • Create React App
    • Babel
  • Developing
  • Sponsors
  • Related
  • Credits
  • Disclaimer

Quickstart

Follow the instructions below to generate a new Typescript package that you can publish to npm.

First, install telescope and create-cosmos-app

npm install -g @cosmology/telescope create-cosmos-app

Generate

Use the create-cosmos-app command to create a new package from the telescope boilerplate.

cca --boilerplate telescope

Then, you'll navigate into ./your-project/packages/telescope package for the next steps.

You can also use telescope generate command to generate package according to the prompt or terminal command params such as: telescope generate --access public --userfullname testname --useremail test@gmail.com --module-desc test --username salkfl --license MIT --module-name test --chain-name cosmos --use-npm-scoped

The available options are: --userfullname --useremail --module-desc --username --module-name --chain-name --access --use-npm-scoped --license

If some required options are missing, it will prompt to ask for the info.

To be noted, --use-npm-scoped only works when --access is public

Download protos with CLI

The old telescope install command has been deprecated

You can use our CLI to download protos by using download command.

telescope download

You should now see some repos cloned in ./git-modules and proto files generated in ./protos. These are the proto files downloaded according to your config.

Examples:

# Telescope will do the download according to .json file of --config
# Telescope will put proto into location specified by --out 
telescope download --config ./protod.config.json --out ./git-modules

# Telescope download from target repo according to --git-repo
# in format of (i.e. <owner>/<repository> or <owner>/<repository>/<branch>)
# <branch> can be empty, it will use main as default
# Also --targets is required to specify the targets to download 
# in format like cosmos/auth/v1beta1/auth.proto
telescope download --git-repo target-repo --targets target-proto

# ssh arg is optional, default is false
telescope download --config ./protod.config.json --out ./git-modules --ssh true

// .protod.config.json example
//
// `repos` are the repository it's going to clone
// in format of (i.e. { "owner": <owner>, "repo": <repo> } or { "owner": <owner>, "repo": <repo>, "branch": <branch> })
// <branch> can be empty, it will use main as default
//
// `protoDirMapping` is the directory of repo specified if the proto is not under repo's root directory ./protos
// in format of (i.e. <owner>/<repository> or <owner>/<repository>/<branch>)
// <branch> can be empty, it will use main as default
//
// `outDir` is where the output proto will be put
//
// `targets` are the target proto to download 
// `targets` can be patterns like:
// "cosmos/bank/v1beta1/tx.proto",
// "cosmos/gov/**/*.proto",
// "cosmos/authz/**/*.proto",
{
  "repos": [
    { "owner": "cosmos", "repo": "cosmos-sdk" },
    ...
  ],
  "protoDirMapping": {
    "gogo/protobuf/master": ".",
    ...
  },
  "outDir": "protos",
  "ssh": true,
  "tempRepoDir": "git-modules",
  "targets": [
    "cosmos/auth/v1beta1/auth.proto",
    ...
  ]
}

Transpile

To create the Typescript files for your chain, run the yarn codegen command inside of the package.

yarn codegen

Transpile with CLI

Less recommended, but you can also use our CLI for transpilation. To create the Typescript files with the cli, run the transpile command.

telescope transpile

You should now see some .ts files generated in ./src. These are the real source files used in your application.

Examples:

# Telescope takes chain1 folder as input,
# and generate files in 'gen/src' folder.
telescope transpile --protoDirs ../../__fixtures__/chain1 --outPath gen/src

# Telescope takes chain1 folder as input,
# and generate files in 'gen/src' folder using default telescope options.
telescope transpile --protoDirs ../../__fixtures__/chain1 --outPath gen/src --useDefaults

# Telescope takes chain1 folder(from args) and chain2 folder(from config) as input,
# and generate files in 'gen/src'(defined in the config file, will override outPath in args) folder using a config file.
# Note: --config will override --useDefaults.
telescope transpile --protoDirs ../../__fixtures__/chain1 --config .telescope.json

# Telescope takes more than one config. The config afterward will override those in front. In this case values in .telescope-ext.json will override those in .telescope.json.
telescope transpile --config .telescope.json --config .telescope-ext.json

//.telescope.json
{
  "protoDirs": [
    "../../fixtures/chain2"
  ],
  "outPath": "gen/src",
  "options": {
    // telescope options
    ...
  }
}

Build

Finally, run install and build to generate the JS and types for publishing your module to npm.

yarn build

Publishing

Now you should have code inside of your ./src folder, ready for publshing. If you used the create-cosmos-app boilerplate, use lerna to publish (and/or read the README in the boilerplate for instructions), or run npm publish from your repository.

Usage

Programatic Usage

First add telescope to your devDependencies:

yarn add --dev @cosmology/telescope

Install helpers and cosmjs dependencies listed here

import { join } from 'path';
import telescope from '@cosmology/telescope';
import { sync as rimraf } from 'rimraf';

const protoDirs = [join(__dirname, '/../proto')];
const outPath = join(__dirname, '../src');
rimraf(outPath);

telescope({
  protoDirs,
  outPath,

  // all options are totally optional ;)
  options: {
    aminoEncoding: {
        enabled: true
    },
    lcdClients: {
        enabled: false
    },
    rpcClients: {
        enabled: false,
        camelCase: true
    },

    // you can scope options to certain packages:
    packages: {
      nebula: {
        prototypes: {
          typingsFormat: {
            useExact: false
          }
        }
      },
      akash: {
        stargateClients: {
            enabled: true,
            includeCosmosDefaultTypes: false
        },
        prototypes: {
          typingsFormat: {
              useExact: false
          }
        }
      }
    }
  }
}).then(() => {
  console.log('✨ all done!');
}).catch(e => {
  console.error(e);
  process.exit(1);
})

Options

Amino Encoding

Implemented Interface Options

Prototypes Options

Prototypes Methods

Enums Options

LCD Client Options

See LCD Clients for more info.

RPC Client Options

See RPC Clients for more info.

Helper Functions

See Helper Functions Configuration for more info.

Stargate Client Options

State Management

React Query

Mobx

Pinia

Typings and Formating

Protobuf parser

Typescript Disabling

ESLint Disabling

Bundle

Output

Types

Timestamp

The representation of google.protobuf.Timestamp is configurable by the prototypes.typingsFormat.timestamp option.

TODO

• add date='string' option

Duration

The representation of google.protobuf.Duration is configurable by the prototypes.typingsFormat.duration option.

Composing Messages

This example shows messages from the osmojs, which was built with Telescope.

Import the osmosis object from osmojs. In this case, we're show the messages available from the osmosis.gamm.v1beta1 module:

import { osmosis } from 'osmojs';

const {
    joinPool,
    exitPool,
    exitSwapExternAmountOut,
    exitSwapShareAmountIn,
    joinSwapExternAmountIn,
    joinSwapShareAmountOut,
    swapExactAmountIn,
    swapExactAmountOut
} = osmosis.gamm.v1beta1.MessageComposer.withTypeUrl;

Now you can construct messages. If you use vscode or another typescript-enabled IDE, you should also be able to use ctrl+space to see auto-completion of the fields required for the message.

import { coin } from '@cosmjs/amino';

const msg = swapExactAmountIn({
  sender,
  routes,
  tokenIn: coin(amount, denom),
  tokenOutMinAmount
});

Calculating Fees

Make sure to create a fee object in addition to your message.

import { coins } from '@cosmjs/amino';

const fee = {
    amount: coins(0, 'uosmo'),
    gas: '250000'
}

if you are broadcasting multiple messages in a batch, you should simulate your tx and estimate the fee

import { Dec, IntPretty } from '@keplr-wallet/unit';

const gasEstimated = await stargateClient.simulate(address, msgs, memo);
const fee = {
  amount: coins(0, 'uosmo'),
  gas: new IntPretty(new Dec(gasEstimated).mul(new Dec(1.3)))
    .maxDecimals(0)
    .locale(false)
    .toString()
};

Stargate Clients

Every module gets their own signing client. This example demonstrates for the osmosis module.

Use getSigningOsmosisClient to get your SigningStargateClient, with the Osmosis proto/amino messages full-loaded. No need to manually add amino types, just require and initialize the client:

import { getSigningOsmosisClient } from 'osmojs';

const client = await getSigningOsmosisClient({
  rpcEndpoint,
  signer // OfflineSigner
});

Creating Signers

To broadcast messages, you'll want to use either keplr or an OfflineSigner from cosmjs using mnemonics.

Amino Signer

Likely you'll want to use the Amino, so unless you need proto, you should use this one:

import { getOfflineSigner as getOfflineSignerAmino } from 'cosmjs-utils';

Proto Signer

import { getOfflineSigner as getOfflineSignerProto } from 'cosmjs-utils';

WARNING: NOT RECOMMENDED TO USE PLAIN-TEXT MNEMONICS. Please take care of your security and use best practices such as AES encryption and/or methods from 12factor applications.

import { chains } from 'chain-registry';

const mnemonic =
    'unfold client turtle either pilot stock floor glow toward bullet car science';
const chain = chains.find(({ chain_name }) => chain_name === 'osmosis');
const signer = await getOfflineSigner({
    mnemonic,
    chain
});

Broadcasting messages

Now that you have your client, you can broadcast messages:

import { signAndBroadcast } from '@osmosnauts/helpers';

const res = await signAndBroadcast({
  client, // SigningStargateClient
  chainId: 'osmosis-1', // use 'osmo-test-4' for testnet
  address,
  msgs: [msg],
  fee,
  memo: ''
});

LCD Clients

For querying data via REST endpoints, you can use LCD Clients. For a better developer experience, you can generate a factory of scoped bundles of all LCD Clients with the lcdClients option.

const options: TelescopeOptions = {
    lcdClients: {
        enabled: true,
    },
};

If you use the lcdClients.scoped array, you can scope to only the modules of your interest.

const options: TelescopeOptions = {
  lcdClients: {
    enabled: true,
    scoped: [
      {
        dir: 'osmosis',
        filename: 'custom-lcd-client.ts',
        packages: [
          'cosmos.bank.v1beta1',
          'cosmos.gov.v1beta1',
          'osmosis.gamm.v1beta1'
        ],
        addToBundle: true,
        methodName: 'createCustomLCDClient'
      },
      {
        dir: 'evmos',
        filename: 'custom-lcd-client.ts',
        packages: [
          'cosmos.bank.v1beta1',
          'cosmos.gov.v1beta1',
          'evmos.erc20.v1'
        ],
        addToBundle: true,
        methodName: 'createEvmosLCDClient'
      }
    ]
  }
};

This will generate a nice helper in the ClientFactory, which you can then use to query multiple modules from a single object:

import { osmosis } from './codegen';

const main = async () => {
   const client = await osmosis.ClientFactory.createLCDClient({ restEndpoint: REST_ENDPOINT });

   // now you can query the modules
   const pool = await client.osmosis.gamm.v1beta1.pool({ poolId: "1" });
   const balance = await client.cosmos.bank.v1beta1.allBalances({ address: 'osmo1addresshere' });
};

LCD Clients Classes

If you want to instantiate a single client, for any module that has a Query type, there will be a LCDQueryClient object:

import { osmosis } from "osmojs";

export const main = async () => {
    const requestClient = new LCDClient({ restEndpoint: REST_ENDPOINT });
    const client = new osmosis.gamm.v1beta1.LCDQueryClient({ requestClient });
    const pools = await client.pools();
    console.log(pools);
};

main().then(() => {
    console.log('all done')
})

RPC Clients

Tendermint Client

For querying data via RPC endpoints, you can use RPC Clients. For a better developer experience, you can generate a factory of scoped bundles of all RPC Clients with the rpcClients option.

const options: TelescopeOptions = {
  rpcClients: {
    type: 'tendermint',
    enabled: true,
    camelCase: true
  }
};

If you use the rpcClients.scoped array, you can scope to only the modules of your interest. gRPC-web and gRPC-gateway work the same way with this option.

const options: TelescopeOptions = {
  rpcClients: {
    enabled: true,
    camelCase: true,
    scoped: [
      {
        dir: 'osmosis',
        filename: 'osmosis-rpc-client.ts',
        packages: [
          'cosmos.bank.v1beta1',
          'cosmos.gov.v1beta1',
          'osmosis.gamm.v1beta1'
        ],
        addToBundle: true,
        methodNameQuery: 'createRPCQueryClient',
        methodNameTx: 'createRPCTxClient'
      }
    ]
  }
};

This will generate helpers createRPCQueryClient and createRPCTxClient in the ClientFactory, which you can then use to query multiple modules from a single object:

import { osmosis } from './codegen';

const main = async () => {
  const client = await osmosis.ClientFactory.createRPCQueryClient({ rpcEndpoint });

  // now you can query the modules
  const pool = await client.osmosis.gamm.v1beta1.pool({ poolId: "1" });
  const balance = await client.cosmos.bank.v1beta1.allBalances({ address: 'osmo1addresshere' });
};

gRPC-web Client

For querying data via gRPC-web endpoints, you can use gRPC-web Clients. For a better developer experience, you can generate a factory of scoped bundles of all gRPC-web Clients with the rpcClients option.

const options: TelescopeOptions = {
  rpcClients: {
    type: 'grpc-web',
    enabled: true,
    camelCase: true
  }
};

This will generate helpers createGrpcWebClient and createGrpcMsgClient in the ClientFactory, which you can then use to query multiple modules from a single object, if you need an example with scaffold and broadcast msg you can refer to the example below in grpc-gateway:

import { osmosis } from './codegen';

const main = async () => {
  const client = await osmosis.ClientFactory.createGrpcWebClient({ endpoint });

  // now you can query the modules
  const pool = await client.osmosis.gamm.v1beta1.pool({ poolId: "1" });
  const balance = await client.cosmos.bank.v1beta1.allBalances({ address: 'osmo1addresshere' });
};

gRPC-gateway Client

For querying data via gRPC-web endpoints, you can use gRPC-web Clients. For a better developer experience, you can generate a factory of scoped bundles of all gRPC-web Clients with the rpcClients option.

const options: TelescopeOptions = {
  rpcClients: {
    type: 'grpc-gateway',
    enabled: true,
    camelCase: true
  }
};

This will generate helpers createGrpcGateWayClient in the ClientFactory, which you can then use to query multiple modules from a single object:

import { osmosis } from './codegen';

const main = async () => {
  // endpoint here is lcd endpoint
  const client = await osmosis.ClientFactory.createGrpcGateWayClient({ endpoint });

  // now you can query the modules
  const pool = await client.osmosis.gamm.v1beta1.pool({ poolId: "1" });
  const balance = await client.cosmos.bank.v1beta1.allBalances({ address: 'osmo1addresshere' });
};

Below will be an example of scaffold a grant Proto Msg for grpc-web and grpc-gateway and then broadcast it.

const { grant } = cosmos.authz.v1beta1.MessageComposer.withTypeUrl;
const msg = grant({
    granter: 'granter_address',
    grantee: 'grantee_address',
    grant: {
        authorization: StakeAuthorization.toProtoMsg({
        maxTokens: {
            denom: 'uosmo',
            amount: '100000000'
        },
        authorizationType: AuthorizationType.AUTHORIZATION_TYPE_DELEGATE
    }),
    expiration: new Date(Date.now() + 60 * 60 * 24 * 7)
}})

const signed_tx = await signClient.sign('granter_address', [msg], fee, 'telescope: grant', signerData);
const txRawBytes = Uint8Array.from(TxRaw.encode(signed_tx).finish());

const res = await client.cosmos.tx.v1beta1.broadcastTx({
    txBytes: txRawBytes,
    mode: BroadcastMode.BROADCAST_MODE_BLOCK
})

console.log(res);

RPC Client Classes

If you want to instantiate a single client, you can generate RPC classes with the rpcClients option;

For any module that has a Msg, Query or Service type, a

import { osmosis, cosmos } from 'osmojs';

const MsgClient = osmosis.gamm.v1beta1.MsgClientImpl;
const QueryClient = osmosis.gamm.v1beta1.QueryClientImpl;
const ServiceClient = cosmos.base.tendermint.v1beta1.ServiceClientImpl;

Here is an example of making a query if you want to use the RPC client classes manually:

import { osmosis } from "osmojs";
import { createProtobufRpcClient, QueryClient } from "@cosmjs/stargate";
import { Tendermint34Client } from "@cosmjs/tendermint-rpc";

export const main = async () => {
    const tmClient = await Tendermint34Client.connect(RPC_ENDPOINT);
    const QueryClientImpl = osmosis.gamm.v1beta1.QueryClientImpl;
    const client = new QueryClient(tmClient);
    const rpc = createProtobufRpcClient(client);
    const queryService = new QueryClientImpl(rpc);
    const pools = await queryService.pools({})
    console.log(pools);
};

main().then(() => {
    console.log('all done')
})

Instant RPC Methods

Using instantOps option to expose instant RPC methods.

For example, for this config:

{
    instantOps: [
      {
        className: "OsmosisClaim",
        include: {
          patterns: ["osmosis.**.*claim*"],
        },
      },
      {
        className: "CosmosAuthAccount",
        include: {
          patterns: [
            "cosmos.auth.**.*account*",
            "cosmos.auth.**.*Account*",
            "cosmos.gov.v1beta1.**",
          ],
        },
        nameMapping: {
          // name mapping rule for both Msg and Query methods.
          // moduleAccounts will be renamed to authModuleAccounts in generated class.
          All: {
            authModuleAccounts: "cosmos.auth.v1beta1.moduleAccounts",
          },
          // name mapping rule for Msg methods.
          Msg: {
            // deposit method under Msg will be renamed to txDeposit in generated class. While deposit method under Query will remain the same.
            txDeposit: "cosmos.gov.v1beta1.deposit",
            // Same for vote method.
            txVote: "cosmos.gov.v1beta1.vote",
          },
        },
      },
    ],
}

There'll be an extra file generated in the root folder called service-ops.ts:

export interface OsmosisClaim extends _OsmosisClaimV1beta1Queryrpc.OsmosisClaim {}
export class OsmosisClaim {
  rpc: TxRpc;
  init(rpc: TxRpc) {
    this.rpc = rpc;
    this.claimRecord = _OsmosisClaimV1beta1Queryrpc.createClientImpl(rpc).claimRecord;
    this.claimableForAction = _OsmosisClaimV1beta1Queryrpc.createClientImpl(rpc).claimableForAction;
  }
}
export interface CosmosAuthAccount extends _CosmosAuthV1beta1Queryrpc.CosmosAuthAccount, _CosmosGovV1beta1Queryrpc.CosmosAuthAccount, _CosmosGovV1beta1Txrpc.CosmosAuthAccount {}
export class CosmosAuthAccount {
  rpc: TxRpc;
  init(rpc: TxRpc) {
    this.rpc = rpc;
    this.accounts = _CosmosAuthV1beta1Queryrpc.createClientImpl(rpc).accounts;
    this.account = _CosmosAuthV1beta1Queryrpc.createClientImpl(rpc).account;

    // moduleAccounts has been renamed to authModuleAccounts as the nameMapping in settings.
    this.authModuleAccounts = _CosmosAuthV1beta1Queryrpc.createClientImpl(rpc).moduleAccounts;

    this.proposal = _CosmosGovV1beta1Queryrpc.createClientImpl(rpc).proposal;
    this.proposals = _CosmosGovV1beta1Queryrpc.createClientImpl(rpc).proposals;

    // vote under Query remains the same.
    this.vote = _CosmosGovV1beta1Queryrpc.createClientImpl(rpc).vote;

    this.votes = _CosmosGovV1beta1Queryrpc.createClientImpl(rpc).votes;
    this.params = _CosmosGovV1beta1Queryrpc.createClientImpl(rpc).params;

    // deposit under Query remains the same.
    this.deposit = _CosmosGovV1beta1Queryrpc.createClientImpl(rpc).deposit;

    this.deposits = _CosmosGovV1beta1Queryrpc.createClientImpl(rpc).deposits;
    this.tallyResult = _CosmosGovV1beta1Queryrpc.createClientImpl(rpc).tallyResult;
    this.submitProposal = _CosmosGovV1beta1Txrpc.createClientImpl(rpc).submitProposal;

    //same as txDeposite for vote here.
    this.txVote = _CosmosGovV1beta1Txrpc.createClientImpl(rpc).vote;

    this.voteWeighted = _CosmosGovV1beta1Txrpc.createClientImpl(rpc).voteWeighted;

    // deposit method under Msg will be renamed to txDeposit in generated class. While deposit method under Query will remain the same.
    this.txDeposit = _CosmosGovV1beta1Txrpc.createClientImpl(rpc).deposit;
  }
}

Combined Clients Methods

Using combined option to generate multiple module clients

For example, for this config:

{
    combinedClient: [
      {
        name: "CosmosIbc",
        fileName: "cosmos-ibc-client.ts",
        include: {
          patterns: [
            "cosmos.gov.v1beta1*",
            "cosmos.gov.v1*",
            "ibc.core.channel.*",
          ],
        },
      },
      {
        name: "AkashCosmos",
        fileName: "akash-cosmos-client.ts",
        include: {
          patterns: [
            "cosmos.group.v1*",
            "cosmos.nft.v1beta1*",
            "akash.**.v1beta2",
            "akash.audit.v1beta1*",
          ],
        },
      },
    ],
}

There'll be client files (cosmos-ibc-client.ts, akash-cosmos-client.ts) generated in the root folder according to fileName in the setting. The combined client will import proto files accroding to include.patterns. (The protos can come from different modules) For example the cosmos-ibc-client.ts will be like:

export const cosmosIbcAminoConverters = {
  ...cosmosGovV1TxAmino.AminoConverter,
  ...cosmosGovV1beta1TxAmino.AminoConverter,
  ...ibcCoreChannelV1TxAmino.AminoConverter
};
export const cosmosIbcProtoRegistry: ReadonlyArray<[string, GeneratedType]> = [...cosmosGovV1TxRegistry.registry, ...cosmosGovV1beta1TxRegistry.registry, ...ibcCoreChannelV1TxRegistry.registry];
export const getCosmosIbcSigningClientOptions = ({
  defaultTypes = defaultRegistryTypes
}: {
  ...
};
export const getCosmosIbcSigningClient = async ({
  rpcEndpoint,
  signer,
  defaultTypes = defaultRegistryTypes
}: {
  rpcEndpoint: string | HttpEndpoint;
  signer: OfflineSigner;
  defaultTypes?: ReadonlyArray<[string, GeneratedType]>;
}) => {
  ...
};

Manually registering types

This example is with osmosis module in osmojs, but it is the same pattern for any module.

NOTE: this is using @cosmjs/stargate@0.28.4

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';

export const getCustomSigningClient = async ({ rpcEndpoint, signer }: { rpcEndpoint: string, signer: OfflineSigner }) => {
  // registry
  const registry = new Registry(defaultRegistryTypes);

  // aminotypes
  const aminoTypes = new AminoTypes({
    ...osmosis.gamm.v1beta1.AminoConverter,
    ...osmosis.lockup.AminoConverter,
    ...osmosis.superfluid.AminoConverter
  });

  // load the
  osmosis.gamm.v1beta1.load(registry);
  osmosis.lockup.load(registry);
  osmosis.superfluid.load(registry);

  const client = await SigningStargateClient.connectWithSigner(
    rpcEndpoint,
    signer,
    { registry, aminoTypes }
  );

  return client;
};

JSON Patch Protos

The prototypes.patch configuration within the options object allows for dynamic modifications to protobuf definitions during code generation. This feature is designed to apply specific changes to proto files without altering the original source. By using JSON Patch operations such as replace and add, developers can customize the generated output to better fit project requirements when upstream SDK PRs are lagging or not in production.

Patches are specified as arrays of Operations, where each operation is defined by:

• op: The operation type (add or replace).
• path: The JSON path to the target field, optionally prefixed with @ to denote paths derived automatically from the package name, simplifying navigation within the proto file's structure.
• value: The new value to be set at the target location specified by the path.

Here is how these patches can be defined within the prototypes configuration:

{
    "prototypes": {
        "patch": {
            "cosmwasm/wasm/v1/types.proto": [
                {
                    "op": "replace",
                    "path": "@/AccessType/valuesOptions/ACCESS_TYPE_UNSPECIFIED/(gogoproto.enumvalue_customname)",
                    "value": "UnspecifiedAccess"
                },
                {
                    "op": "replace",
                    "path": "@/AccessType/valuesOptions/ACCESS_TYPE_NOBODY/(gogoproto.enumvalue_customname)",
                    "value": "NobodyAccess"
                },
                {
                    "op": "add",
                    "path": "@/AccessType/values/ACCESS_TYPE_SUPER_FUN",
                    "value": 4
                },
                {
                    "op": "add",
                    "path": "@/AccessType/valuesOptions/ACCESS_TYPE_SUPER_FUN",
                    "value": {
                        "(gogoproto.enumvalue_customname)": "SuperFunAccessType"
                    }
                }
            ]
        }
    }
}

CosmWasm

Generate TypeScript SDKs for your CosmWasm smart contracts by using the cosmwasm option on TelescopeOptions. The cosmwasm option is actually a direct reference to the TSBuilderInput object, for the most up-to-date documentation, visit @cosmwasm/ts-codegen.

import { TSBuilderInput } from '@cosmwasm/ts-codegen';
const options: TelescopeOptions = {
  cosmwasm: {
    contracts: [
      {
        name: 'SG721',
        dir: './path/to/sg721/schema'
      },
      {
        name: 'Minter',
        dir: './path/to/Minter/schema'
      }
    ],
    outPath: './path/to/code/src/'
  }
};

Helper Functions Configuration

The nameMappers object supports three service types: All, Query, and Msg. Each pattern within these categories can specify:

{
  "pattern": {
    funcBody: (name: string) => string,    // Function to transform the method name
    creatorPrefix?: string,                // Prefix for the creator function (default: "create")
    hookPrefix?: string                    // Prefix for the hook function (default: "use")
  }
}

const options: TelescopeOptions = {
  helperFuncCreators: {
    enabled: true,
    genCustomHooks: true,
    include: {
      patterns: ["cosmos.gov.v1beta1.**", "cosmos.bank.v1beta1.*Send*"],
    },
    nameMappers: {
      All: {
        "cosmos.gov.v1beta1.*Vote*": {
          funcBody: (name) => `helper${name}`,
          creatorPrefix: "build",
          hookPrefix: "use",
        },
      },
      Query: {
        "cosmos.gov.v1beta1.*Deposits*": {
          funcBody: (name) => `goOver${name}`,
        },
      },
      Msg: {
        "cosmos.gov.v1beta1.*VoteWeighted*": {
          funcBody: (name) => `lets${name}`,
          creatorPrefix: "construct",
          hookPrefix: "useTx",
        },
      },
    },
  },
};

Pattern Matching Priority:

1. Service-specific patterns (Query, Msg) take precedence over All patterns
2. More specific patterns take precedence over general patterns
3. Patterns are case-sensitive

Generated Output Examples:

• For a method named VoteWeighted:
• Default: createVoteWeighted and useVoteWeighted
• With custom mapping: constructLetsVoteWeighted and useTxLetsVoteWeighted

Notes:

• Patterns support glob-style matching (e.g., **, *)
• Each service type can have its own naming conventions
• Custom prefixes are optional; defaults will be used if not specified
• Function body transformations can be customized using the funcBody property

Dependencies

If you don't use the boilerplate, you will need to manually install

• @cosmjs/amino
• @cosmjs/proto-signing
• @cosmjs/stargate
• @cosmjs/tendermint-rpc

yarn add @cosmjs/amino @cosmjs/proto-signing @cosmjs/stargate @cosmjs/tendermint-rpc

If you use the LCD Client generation, you'll need to add

• @cosmology/lcd

yarn add @cosmology/lcd

Troubleshooting

Create React App

CRA requires that you update Webpack configurations:

https://github.com/cosmos/cosmjs/blob/656e02374898afe755e980e93390591b4b65fd86/README.md#webpack-configs

Here is an example of a config-overrides.js:

https://github.com/pyramation/osmosis-ui/blob/main/config-overrides.js

Babel

This should not be an issue, but if you experience problems with syntax or are not using preset-env, you may need these babel plugins:

• babel-plugin-proposal-numeric-separator
• babel-plugin-proposal-optional-chaining
• babel-plugin-proposal-nullish-coalescing-operator

Developing

See our documentation for how to contribute and develop Telescope.

Sponsors

Kudos to our sponsors:

• Osmosis funded the creation of Telescope.

Related

Checkout these related projects:

• @cosmology/telescope Your Frontend Companion for Building with TypeScript with Cosmos SDK Modules.
• @cosmwasm/ts-codegen Convert your CosmWasm smart contracts into dev-friendly TypeScript classes.
• chain-registry Everything from token symbols, logos, and IBC denominations for all assets you want to support in your application.
• cosmos-kit Experience the convenience of connecting with a variety of web3 wallets through a single, streamlined interface.
• create-cosmos-app Set up a modern Cosmos app by running one command.
• interchain-ui The Interchain Design System, empowering developers with a flexible, easy-to-use UI kit.
• starship Unified Testing and Development for the Interchain.

Credits

🛠 Built by Cosmology — if you like our tools, please consider delegating to our validator ⚛️

Thanks to these engineers, teams and projects for inspiring Telescope:

• @webmaster128
• @assafmo
• osmosis-frontend
• cosmjs
• ts-proto
• keplr-wallet

Disclaimer

AS DESCRIBED IN THE TELESCOPE LICENSES, THE SOFTWARE IS PROVIDED “AS IS”, AT YOUR OWN RISK, AND WITHOUT WARRANTIES OF ANY KIND.

No developer or entity involved in creating Telescope will be liable for any claims or damages whatsoever associated with your use, inability to use, or your interaction with other users of the Telescope code or Telescope CLI, including any direct, indirect, incidental, special, exemplary, punitive or consequential damages, or loss of profits, cryptocurrencies, tokens, or anything else of value.