From a403dfc83e14c59a317ed90509fa289bcd270691 Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" <41898282+github-actions[bot]@users.noreply.github.com> Date: Mon, 12 Sep 2022 11:33:35 +0300 Subject: [PATCH] docs(cli): update generated docs (#2693) Co-authored-by: ilgooz --- docs/docs/07-cli.md | 1218 +++++++++++++++++++++++++++++++++++++------ 1 file changed, 1053 insertions(+), 165 deletions(-) diff --git a/docs/docs/07-cli.md b/docs/docs/07-cli.md index cff1cffeae..ded778d73d 100644 --- a/docs/docs/07-cli.md +++ b/docs/docs/07-cli.md @@ -1,5 +1,5 @@ --- -sidebar_position: 8 +sidebar_position: 7 description: Ignite CLI docs. --- @@ -18,9 +18,7 @@ test, build, and launch your blockchain. To get started, create a blockchain: -``` -ignite scaffold chain mars -``` +ignite scaffold chain github.com/username/mars **Options** @@ -30,10 +28,12 @@ ignite scaffold chain mars **SEE ALSO** -* [ignite account](#ignite-account) - Commands for managing accounts +* [ignite account](#ignite-account) - Commands for managing Ignite accounts * [ignite chain](#ignite-chain) - Build, initialize and start a blockchain node or perform other actions on the blockchain +* [ignite completion](#ignite-completion) - Generate the autocompletion script for the specified shell * [ignite docs](#ignite-docs) - Show Ignite CLI docs * [ignite generate](#ignite-generate) - Generate clients, API docs from source code +* [ignite node](#ignite-node) - Make calls to a live blockchain node * [ignite relayer](#ignite-relayer) - Connect blockchains by using IBC protocol * [ignite scaffold](#ignite-scaffold) - Scaffold a new blockchain, module, message, query, and more * [ignite tools](#ignite-tools) - Tools for advanced users @@ -42,17 +42,26 @@ ignite scaffold chain mars ## ignite account -Commands for managing accounts +Commands for managing Ignite accounts **Synopsis** -Commands for managing accounts. An account is a pair of a private key and a public key. -Ignite CLI uses accounts to interact with the Ignite blockchain, use an IBC relayer, and more. +Commands for managing Ignite accounts. An Ignite account is a private/public +keypair stored in a keyring. Currently Ignite accounts are used when interacting +with Ignite relayer commands. + +Note: Ignite account commands are not for managing your chain's keys and accounts. Use +you chain's binary to manage accounts from "config.yml". For example, if your +blockchain is called "mychain", use "mychaind keys" to manage keys for the +chain. + **Options** ``` - -h, --help help for account + -h, --help help for account + --keyring-backend string Keyring backend to store your account keys (default "test") + --keyring-dir string The accounts keyring directory (default "/home/runner/.ignite/accounts") ``` **SEE ALSO** @@ -77,13 +86,19 @@ ignite account create [name] [flags] **Options** ``` - -h, --help help for create + -h, --help help for create +``` + +**Options inherited from parent commands** + +``` --keyring-backend string Keyring backend to store your account keys (default "test") + --keyring-dir string The accounts keyring directory (default "/home/runner/.ignite/accounts") ``` **SEE ALSO** -* [ignite account](#ignite-account) - Commands for managing accounts +* [ignite account](#ignite-account) - Commands for managing Ignite accounts ## ignite account delete @@ -97,13 +112,19 @@ ignite account delete [name] [flags] **Options** ``` - -h, --help help for delete + -h, --help help for delete +``` + +**Options inherited from parent commands** + +``` --keyring-backend string Keyring backend to store your account keys (default "test") + --keyring-dir string The accounts keyring directory (default "/home/runner/.ignite/accounts") ``` **SEE ALSO** -* [ignite account](#ignite-account) - Commands for managing accounts +* [ignite account](#ignite-account) - Commands for managing Ignite accounts ## ignite account export @@ -117,16 +138,22 @@ ignite account export [name] [flags] **Options** ``` - -h, --help help for export + -h, --help help for export + --non-interactive Do not enter into interactive mode + --passphrase string Passphrase to encrypt the exported key + --path string path to export private key. default: ./key_[name] +``` + +**Options inherited from parent commands** + +``` --keyring-backend string Keyring backend to store your account keys (default "test") - --non-interactive Do not enter into interactive mode - --passphrase string Account passphrase - --path string path to export private key. default: ./key_[name] + --keyring-dir string The accounts keyring directory (default "/home/runner/.ignite/accounts") ``` **SEE ALSO** -* [ignite account](#ignite-account) - Commands for managing accounts +* [ignite account](#ignite-account) - Commands for managing Ignite accounts ## ignite account import @@ -140,16 +167,22 @@ ignite account import [name] [flags] **Options** ``` - -h, --help help for import + -h, --help help for import + --non-interactive Do not enter into interactive mode + --passphrase string Passphrase to decrypt the imported key (ignored when secret is a mnemonic) + --secret string Your mnemonic or path to your private key (use interactive mode instead to securely pass your mnemonic) +``` + +**Options inherited from parent commands** + +``` --keyring-backend string Keyring backend to store your account keys (default "test") - --non-interactive Do not enter into interactive mode - --passphrase string Account passphrase - --secret string Your mnemonic or path to your private key (use interactive mode instead to securely pass your mnemonic) + --keyring-dir string The accounts keyring directory (default "/home/runner/.ignite/accounts") ``` **SEE ALSO** -* [ignite account](#ignite-account) - Commands for managing accounts +* [ignite account](#ignite-account) - Commands for managing Ignite accounts ## ignite account list @@ -163,14 +196,20 @@ ignite account list [flags] **Options** ``` - --address-prefix string Account address prefix (default "cosmos") - -h, --help help for list + --address-prefix string Account address prefix (default "cosmos") + -h, --help help for list +``` + +**Options inherited from parent commands** + +``` --keyring-backend string Keyring backend to store your account keys (default "test") + --keyring-dir string The accounts keyring directory (default "/home/runner/.ignite/accounts") ``` **SEE ALSO** -* [ignite account](#ignite-account) - Commands for managing accounts +* [ignite account](#ignite-account) - Commands for managing Ignite accounts ## ignite account show @@ -184,14 +223,20 @@ ignite account show [name] [flags] **Options** ``` - --address-prefix string Account address prefix (default "cosmos") - -h, --help help for show + --address-prefix string Account address prefix (default "cosmos") + -h, --help help for show +``` + +**Options inherited from parent commands** + +``` --keyring-backend string Keyring backend to store your account keys (default "test") + --keyring-dir string The accounts keyring directory (default "/home/runner/.ignite/accounts") ``` **SEE ALSO** -* [ignite account](#ignite-account) - Commands for managing accounts +* [ignite account](#ignite-account) - Commands for managing Ignite accounts ## ignite chain @@ -200,7 +245,54 @@ Build, initialize and start a blockchain node or perform other actions on the bl **Synopsis** -Build, initialize and start a blockchain node or perform other actions on the blockchain. +Commands in this namespace let you to build, initialize, and start your +blockchain node locally for development purposes. + +To run these commands you should be inside the project's directory so that +Ignite can find the source code. To ensure that you are, run "ls", you should +see the following files in the output: "go.mod", "x", "proto", "app", etc. + +By default the "build" command will identify the "main" package of the project, +install dependencies if necessary, set build flags, compile the project into a +binary and install the binary. The "build" command is useful if you just want +the compiled binary, for example, to initialize and start the chain manually. It +can also be used to release your chain's binaries automatically as part of +continuous integration workflow. + +The "init" command will build the chain's binary and use it to initialize a +local validator node. By default the validator node will be initialized in your +$HOME directory in a hidden directory that matches the name of your project. +This directory is called a data directory and contains a chain's genesis file +and a validator key. This command is useful if you want to quickly build and +initialize the data directory and use the chain's binary to manually start the +blockchain. The "init" command is meant only for development purposes, not +production. + +The "serve" command builds, initializes, and starts your blockchain locally with +a single validator node for development purposes. "serve" also watches the +source code directory for file changes and intelligently +re-builds/initializes/starts the chain, essentially providing "code-reloading". +The "serve" command is meant only for development purposes, not production. + +To distinguish between production and development consider the following. + +In production, blockchains often run the same software on many validator nodes +that are run by different people and entities. To launch a blockchain in +production, the validator entities coordinate the launch process to start their +nodes simultaneously. + +During development, a blockchain can be started locally on a single validator +node. This convenient process lets you restart a chain quickly and iterate +faster. Starting a chain on a single node in development is similar to starting +a traditional web application on a local server. + +The "faucet" command lets you send tokens to an address from the "faucet" +account defined in "config.yml". Alternatively, you can use the chain's binary +to send token from any other account that exists on chain. + +The "simulate" command helps you start a simulation testing process for your +chain. + **Options** @@ -224,17 +316,58 @@ Build a node binary **Synopsis** -By default, build your node binaries -and add the binaries to your $(go env GOPATH)/bin path. -To build binaries for a release, use the --release flag. The app binaries -for one or more specified release targets are built in a release/ dir under the app's -source. Specify the release targets with GOOS:GOARCH build tags. -If the optional --release.targets is not specified, a binary is created for your current environment. +The build command compiles the source code of the project into a binary and +installs the binary in the $(go env GOPATH)/bin directory. + +You can customize the output directory for the binary using a flag: + + ignite chain build --output dist + +To compile the binary Ignite first compiles protocol buffer (proto) files into +Go source code. Proto files contain required type and services definitions. If +you're using another program to compile proto files, you can use a flag to tell +Ignite to skip the proto compilation step: + + ignite chain build --skip-proto + +Afterwards, Ignite install dependencies specified in the go.mod file. By default +Ignite doesn't check that dependencies of the main module stored in the module +cache have not been modified since they were downloaded. To enforce dependency +checking (essentially, running "go mod verify") use a flag: + + ignite chain build --check-dependencies + +Next, Ignite identifies the "main" package of the project. By default the "main" +package is located in "cmd/{app}d" directory, where "{app}" is the name of the +scaffolded project and "d" stands for daemon. If your your project contains more +than one "main" package, specify the path to the one that Ignite should compile +in config.yml: + +build: + main: custom/path/to/main + +By default the binary name will match the top-level module name (specified in +go.mod) with a suffix "d". This can be customized in config.yml: + +build: + binary: mychaind + +You can also specify custom linker flags: + +build: + ldflags: + - "-X main.Version=development" + - "-X main.Date=01/05/2022T19:54" + +To build binaries for a release, use the --release flag. The binaries for one or +more specified release targets are built in a "release/" directory in the +project's source directory. Specify the release targets with GOOS:GOARCH build +tags. If the optional --release.targets is not specified, a binary is created +for your current environment. + + ignite chain build --release -t linux:amd64 -t darwin:amd64 -t darwin:arm64 -Sample usages: - - ignite chain build - - ignite chain build --release -t linux:amd64 -t darwin:amd64 -t darwin:arm64 ``` ignite chain build [flags] @@ -243,16 +376,17 @@ ignite chain build [flags] **Options** ``` - --clear-cache Clear the build cache (advanced) + --check-dependencies verify that cached dependencies have not been modified since they were downloaded + --clear-cache clear the build cache (advanced) -h, --help help for build - --home string Home directory used for blockchains -o, --output string binary output path -p, --path string path of the app (default ".") - --proto-all-modules Enables proto code generation for 3rd party modules used in your chain. Available only without the --release flag + --proto-all-modules enables proto code generation for 3rd party modules used in your chain. Available only without the --release flag --release build for a release --release.prefix string tarball prefix for each release target. Available only with --release flag -t, --release.targets strings release targets. Available only with --release flag - -v, --verbose Verbose output + --skip-proto skip file generation from proto + -v, --verbose verbose output ``` **SEE ALSO** @@ -272,7 +406,7 @@ ignite chain faucet [address] [coin<,...>] [flags] ``` -h, --help help for faucet - --home string Home directory used for blockchains + --home string home directory used for blockchains -p, --path string path of the app (default ".") -v, --verbose Verbose output ``` @@ -286,6 +420,70 @@ ignite chain faucet [address] [coin<,...>] [flags] Initialize your chain +**Synopsis** + +The init command compiles and installs the binary (like "ignite chain build") +and uses that binary to initialize the blockchain's data directory for one +validator. To learn how the build process works, refer to "ignite chain build +--help". + +By default, the data directory will be initialized in $HOME/.mychain, where +"mychain" is the name of the project. To set a custom data directory use the +--home flag or set the value in config.yml: + +init: + home: "~/.customdir" + +The data directory contains three files in the "config" directory: app.toml, +config.toml, client.toml. These files let you customize the behavior of your +blockchain node and the client executable. When a chain is re-initialized the +data directory can be reset. To make some values in these files persistent, set +them in config.yml: + +init: + app: + minimum-gas-prices: "0.025stake" + config: + consensus: + timeout_commit: "5s" + timeout_propose: "5s" + client: + output: "json" + +The configuration above changes the minimum gas price of the validator (by +default the gas price is set to 0 to allow "free" transactions), sets the block +time to 5s, and changes the output format to JSON. To see what kind of values +this configuration accepts see the generated TOML files in the data directory. + +As part of the initialization process Ignite creates on-chain accounts with +token balances. By default, config.yml has two accounts in the top-level +"accounts" property. You can add more accounts and change their token balances. +Refer to config.yml guide to see which values you can set. + +One of these accounts is a validator account and the amount of self-delegated +tokens can be set in the top-level "validator" property. + +One of the most important components of an initialized chain is the genesis +file, the 0th block of the chain. The genesis file is stored in the data +directory "config" subdirectory and contains the initial state of the chain, +including consensus and module parameters. You can customize the values of the +genesis in config.yml: + +genesis: + app_state: + staking: + params: + bond_denom: "foo" + +The example above changes the staking token to "foo". If you change the staking +denom, make sure the validator account has the right tokens. + +The init command is meant to be used ONLY FOR DEVELOPMENT PURPOSES. Under the +hood it runs commands like "appd init", "appd add-genesis-account", "appd +gentx", and "appd collect-gentx". For production, you may want to run these +commands manually to ensure a production-level node initialization. + + ``` ignite chain init [flags] ``` @@ -293,10 +491,12 @@ ignite chain init [flags] **Options** ``` - --clear-cache Clear the build cache (advanced) - -h, --help help for init - --home string Home directory used for blockchains - -p, --path string path of the app (default ".") + --check-dependencies verify that cached dependencies have not been modified since they were downloaded + --clear-cache clear the build cache (advanced) + -h, --help help for init + --home string home directory used for blockchains + -p, --path string path of the app (default ".") + --skip-proto skip file generation from proto ``` **SEE ALSO** @@ -310,7 +510,39 @@ Start a blockchain node in development **Synopsis** -Start a blockchain node with automatic reloading +The serve command compiles and installs the binary (like "ignite chain build"), +uses that binary to initialize the blockchain's data directory for one validator +(like "ignite chain init"), and starts the node locally for development purposes +with automatic code reloading. + +Automatic code reloading means Ignite starts watching the project directory. +Whenever a file change is detected, Ignite automatically rebuilds, reinitializes +and restarts the node. + +Whenever possible Ignite will try to keep the current state of the chain by +exporting and importing the genesis file. + +To force Ignite to start from a clean slate even if a genesis file exists, use +the following flag: + + ignite chain serve --reset-once + +To force Ignite to reset the state every time the source code is modified, use +the following flag: + + ignite chain serve --force-reset + +With Ignite it's possible to start more than one blockchain from the same source +code using different config files. This is handy if you're building +inter-blockchain functionality and, for example, want to try sending packets +from one blockchain to another. To start a node using a specific config file: + + ignite chain serve --config mars.yml + +The serve command is meant to be used ONLY FOR DEVELOPMENT PURPOSES. Under the +hood, it runs "appd start", where "appd" is the name of your chain's binary. For +production, you may want to run "appd start" manually. + ``` ignite chain serve [flags] @@ -319,15 +551,17 @@ ignite chain serve [flags] **Options** ``` - --clear-cache Clear the build cache (advanced) - -c, --config string Ignite config file (default: ./config.yml) - -f, --force-reset Force reset of the app state on start and every source change - -h, --help help for serve - --home string Home directory used for blockchains - -p, --path string path of the app (default ".") - --proto-all-modules Enables proto code generation for 3rd party modules used in your chain - -r, --reset-once Reset of the app state on first start - -v, --verbose Verbose output + --check-dependencies verify that cached dependencies have not been modified since they were downloaded + --clear-cache clear the build cache (advanced) + -c, --config string Ignite config file (default: ./config.yml) + -f, --force-reset Force reset of the app state on start and every source change + -h, --help help for serve + --home string home directory used for blockchains + -p, --path string path of the app (default ".") + --proto-all-modules enables proto code generation for 3rd party modules used in your chain + -r, --reset-once Reset of the app state on first start + --skip-proto skip file generation from proto + -v, --verbose Verbose output ``` **SEE ALSO** @@ -374,6 +608,188 @@ ignite chain simulate [flags] * [ignite chain](#ignite-chain) - Build, initialize and start a blockchain node or perform other actions on the blockchain +## ignite completion + +Generate the autocompletion script for the specified shell + +**Synopsis** + +Generate the autocompletion script for ignite for the specified shell. +See each sub-command's help for details on how to use the generated script. + + +**Options** + +``` + -h, --help help for completion +``` + +**SEE ALSO** + +* [ignite](#ignite) - Ignite CLI offers everything you need to scaffold, test, build, and launch your blockchain +* [ignite completion bash](#ignite-completion-bash) - Generate the autocompletion script for bash +* [ignite completion fish](#ignite-completion-fish) - Generate the autocompletion script for fish +* [ignite completion powershell](#ignite-completion-powershell) - Generate the autocompletion script for powershell +* [ignite completion zsh](#ignite-completion-zsh) - Generate the autocompletion script for zsh + + +## ignite completion bash + +Generate the autocompletion script for bash + +**Synopsis** + +Generate the autocompletion script for the bash shell. + +This script depends on the 'bash-completion' package. +If it is not installed already, you can install it via your OS's package manager. + +To load completions in your current shell session: + + source <(ignite completion bash) + +To load completions for every new session, execute once: + +**#### Linux:** + + ignite completion bash > /etc/bash_completion.d/ignite + +**#### macOS:** + + ignite completion bash > $(brew --prefix)/etc/bash_completion.d/ignite + +You will need to start a new shell for this setup to take effect. + + +``` +ignite completion bash +``` + +**Options** + +``` + -h, --help help for bash + --no-descriptions disable completion descriptions +``` + +**SEE ALSO** + +* [ignite completion](#ignite-completion) - Generate the autocompletion script for the specified shell + + +## ignite completion fish + +Generate the autocompletion script for fish + +**Synopsis** + +Generate the autocompletion script for the fish shell. + +To load completions in your current shell session: + + ignite completion fish | source + +To load completions for every new session, execute once: + + ignite completion fish > ~/.config/fish/completions/ignite.fish + +You will need to start a new shell for this setup to take effect. + + +``` +ignite completion fish [flags] +``` + +**Options** + +``` + -h, --help help for fish + --no-descriptions disable completion descriptions +``` + +**SEE ALSO** + +* [ignite completion](#ignite-completion) - Generate the autocompletion script for the specified shell + + +## ignite completion powershell + +Generate the autocompletion script for powershell + +**Synopsis** + +Generate the autocompletion script for powershell. + +To load completions in your current shell session: + + ignite completion powershell | Out-String | Invoke-Expression + +To load completions for every new session, add the output of the above command +to your powershell profile. + + +``` +ignite completion powershell [flags] +``` + +**Options** + +``` + -h, --help help for powershell + --no-descriptions disable completion descriptions +``` + +**SEE ALSO** + +* [ignite completion](#ignite-completion) - Generate the autocompletion script for the specified shell + + +## ignite completion zsh + +Generate the autocompletion script for zsh + +**Synopsis** + +Generate the autocompletion script for the zsh shell. + +If shell completion is not already enabled in your environment you will need +to enable it. You can execute the following once: + + echo "autoload -U compinit; compinit" >> ~/.zshrc + +To load completions in your current shell session: + + source <(ignite completion zsh); compdef _ignite ignite + +To load completions for every new session, execute once: + +**#### Linux:** + + ignite completion zsh > "${fpath[1]}/_ignite" + +**#### macOS:** + + ignite completion zsh > $(brew --prefix)/share/zsh/site-functions/_ignite + +You will need to start a new shell for this setup to take effect. + + +``` +ignite completion zsh [flags] +``` + +**Options** + +``` + -h, --help help for zsh + --no-descriptions disable completion descriptions +``` + +**SEE ALSO** + +* [ignite completion](#ignite-completion) - Generate the autocompletion script for the specified shell + + ## ignite docs Show Ignite CLI docs @@ -408,7 +824,7 @@ Produced source code can be regenerated by running a command again and is not me **Options** ``` - --clear-cache Clear the build cache (advanced) + --clear-cache clear the build cache (advanced) -h, --help help for generate -p, --path string path of the app (default ".") ``` @@ -419,7 +835,8 @@ Produced source code can be regenerated by running a command again and is not me * [ignite generate dart](#ignite-generate-dart) - Generate a Dart client * [ignite generate openapi](#ignite-generate-openapi) - Generate generates an OpenAPI spec for your chain from your config.yml * [ignite generate proto-go](#ignite-generate-proto-go) - Generate proto based Go code needed for the app's source code -* [ignite generate vuex](#ignite-generate-vuex) - Generate Vuex store for you chain's frontend from your config.yml +* [ignite generate ts-client](#ignite-generate-ts-client) - Generate Typescript client for your chain's frontend +* [ignite generate vuex](#ignite-generate-vuex) - Generate Typescript client and Vuex stores for your chain's frontend from your `config.yml` file ## ignite generate dart @@ -440,7 +857,7 @@ ignite generate dart [flags] **Options inherited from parent commands** ``` - --clear-cache Clear the build cache (advanced) + --clear-cache clear the build cache (advanced) -p, --path string path of the app (default ".") ``` @@ -467,7 +884,7 @@ ignite generate openapi [flags] **Options inherited from parent commands** ``` - --clear-cache Clear the build cache (advanced) + --clear-cache clear the build cache (advanced) -p, --path string path of the app (default ".") ``` @@ -494,7 +911,35 @@ ignite generate proto-go [flags] **Options inherited from parent commands** ``` - --clear-cache Clear the build cache (advanced) + --clear-cache clear the build cache (advanced) + -p, --path string path of the app (default ".") +``` + +**SEE ALSO** + +* [ignite generate](#ignite-generate) - Generate clients, API docs from source code + + +## ignite generate ts-client + +Generate Typescript client for your chain's frontend + +``` +ignite generate ts-client [flags] +``` + +**Options** + +``` + -h, --help help for ts-client + --proto-all-modules enables proto code generation for 3rd party modules used in your chain + -y, --yes Answers interactive yes/no questions with yes +``` + +**Options inherited from parent commands** + +``` + --clear-cache clear the build cache (advanced) -p, --path string path of the app (default ".") ``` @@ -505,7 +950,7 @@ ignite generate proto-go [flags] ## ignite generate vuex -Generate Vuex store for you chain's frontend from your config.yml +Generate Typescript client and Vuex stores for your chain's frontend from your `config.yml` file ``` ignite generate vuex [flags] @@ -515,14 +960,14 @@ ignite generate vuex [flags] ``` -h, --help help for vuex - --proto-all-modules Enables proto code generation for 3rd party modules used in your chain + --proto-all-modules enables proto code generation for 3rd party modules used in your chain -y, --yes Answers interactive yes/no questions with yes ``` **Options inherited from parent commands** ``` - --clear-cache Clear the build cache (advanced) + --clear-cache clear the build cache (advanced) -p, --path string path of the app (default ".") ``` @@ -531,6 +976,225 @@ ignite generate vuex [flags] * [ignite generate](#ignite-generate) - Generate clients, API docs from source code +## ignite node + +Make calls to a live blockchain node + +**Options** + +``` + -h, --help help for node + --node string : to tendermint rpc interface for this chain (default "https://rpc.cosmos.network:443") +``` + +**SEE ALSO** + +* [ignite](#ignite) - Ignite CLI offers everything you need to scaffold, test, build, and launch your blockchain +* [ignite node query](#ignite-node-query) - Querying subcommands +* [ignite node tx](#ignite-node-tx) - Transactions subcommands + + +## ignite node query + +Querying subcommands + +**Options** + +``` + -h, --help help for query +``` + +**Options inherited from parent commands** + +``` + --node string : to tendermint rpc interface for this chain (default "https://rpc.cosmos.network:443") +``` + +**SEE ALSO** + +* [ignite node](#ignite-node) - Make calls to a live blockchain node +* [ignite node query bank](#ignite-node-query-bank) - Querying commands for the bank module +* [ignite node query tx](#ignite-node-query-tx) - Query for transaction by hash + + +## ignite node query bank + +Querying commands for the bank module + +**Options** + +``` + -h, --help help for bank +``` + +**Options inherited from parent commands** + +``` + --node string : to tendermint rpc interface for this chain (default "https://rpc.cosmos.network:443") +``` + +**SEE ALSO** + +* [ignite node query](#ignite-node-query) - Querying subcommands +* [ignite node query bank balances](#ignite-node-query-bank-balances) - Query for account balances by account name or address + + +## ignite node query bank balances + +Query for account balances by account name or address + +``` +ignite node query bank balances [from_account_or_address] [flags] +``` + +**Options** + +``` + --address-prefix string Account address prefix (default "cosmos") + --count-total count total number of records in all balances to query for + -h, --help help for balances + --home string home directory used for blockchains + --keyring-backend string Keyring backend to store your account keys (default "test") + --keyring-dir string The accounts keyring directory (default "/home/runner/.ignite/accounts") + --limit uint pagination limit of all balances to query for (default 100) + --offset uint pagination offset of all balances to query for + --page uint pagination page of all balances to query for. This sets offset to a multiple of limit (default 1) + --page-key string pagination page-key of all balances to query for + --reverse results are sorted in descending order +``` + +**Options inherited from parent commands** + +``` + --node string : to tendermint rpc interface for this chain (default "https://rpc.cosmos.network:443") +``` + +**SEE ALSO** + +* [ignite node query bank](#ignite-node-query-bank) - Querying commands for the bank module + + +## ignite node query tx + +Query for transaction by hash + +``` +ignite node query tx [hash] [flags] +``` + +**Options** + +``` + -h, --help help for tx +``` + +**Options inherited from parent commands** + +``` + --node string : to tendermint rpc interface for this chain (default "https://rpc.cosmos.network:443") +``` + +**SEE ALSO** + +* [ignite node query](#ignite-node-query) - Querying subcommands + + +## ignite node tx + +Transactions subcommands + +**Options** + +``` + --address-prefix string Account address prefix (default "cosmos") + --broadcast-mode string Transaction broadcasting mode (sync|async|block), use sync if you encounter timeouts (default "block") + --fees string Fees to pay along with transaction; eg: 10uatom + --gas string gas limit to set per-transaction; set to "auto" to calculate sufficient gas automatically (default "auto") + --gas-prices string Gas prices in decimal format to determine the transaction fee (e.g. 0.1uatom) + --generate-only Build an unsigned transaction and write it to STDOUT + -h, --help help for tx + --home string home directory used for blockchains + --keyring-backend string Keyring backend to store your account keys (default "test") + --keyring-dir string The accounts keyring directory (default "/home/runner/.ignite/accounts") +``` + +**Options inherited from parent commands** + +``` + --node string : to tendermint rpc interface for this chain (default "https://rpc.cosmos.network:443") +``` + +**SEE ALSO** + +* [ignite node](#ignite-node) - Make calls to a live blockchain node +* [ignite node tx bank](#ignite-node-tx-bank) - Bank transaction subcommands + + +## ignite node tx bank + +Bank transaction subcommands + +**Options** + +``` + -h, --help help for bank +``` + +**Options inherited from parent commands** + +``` + --address-prefix string Account address prefix (default "cosmos") + --broadcast-mode string Transaction broadcasting mode (sync|async|block), use sync if you encounter timeouts (default "block") + --fees string Fees to pay along with transaction; eg: 10uatom + --gas string gas limit to set per-transaction; set to "auto" to calculate sufficient gas automatically (default "auto") + --gas-prices string Gas prices in decimal format to determine the transaction fee (e.g. 0.1uatom) + --generate-only Build an unsigned transaction and write it to STDOUT + --home string home directory used for blockchains + --keyring-backend string Keyring backend to store your account keys (default "test") + --keyring-dir string The accounts keyring directory (default "/home/runner/.ignite/accounts") + --node string : to tendermint rpc interface for this chain (default "https://rpc.cosmos.network:443") +``` + +**SEE ALSO** + +* [ignite node tx](#ignite-node-tx) - Transactions subcommands +* [ignite node tx bank send](#ignite-node-tx-bank-send) - Send funds from one account to another. + + +## ignite node tx bank send + +Send funds from one account to another. + +``` +ignite node tx bank send [from_account_or_address] [to_account_or_address] [amount] [flags] +``` + +**Options** + +``` + -h, --help help for send +``` + +**Options inherited from parent commands** + +``` + --address-prefix string Account address prefix (default "cosmos") + --broadcast-mode string Transaction broadcasting mode (sync|async|block), use sync if you encounter timeouts (default "block") + --fees string Fees to pay along with transaction; eg: 10uatom + --gas string gas limit to set per-transaction; set to "auto" to calculate sufficient gas automatically (default "auto") + --gas-prices string Gas prices in decimal format to determine the transaction fee (e.g. 0.1uatom) + --generate-only Build an unsigned transaction and write it to STDOUT + --home string home directory used for blockchains + --keyring-backend string Keyring backend to store your account keys (default "test") + --keyring-dir string The accounts keyring directory (default "/home/runner/.ignite/accounts") + --node string : to tendermint rpc interface for this chain (default "https://rpc.cosmos.network:443") +``` + +**SEE ALSO** + +* [ignite node tx bank](#ignite-node-tx-bank) - Bank transaction subcommands + + ## ignite relayer Connect blockchains by using IBC protocol @@ -562,6 +1226,7 @@ ignite relayer configure [flags] -a, --advanced Advanced configuration options for custom IBC modules -h, --help help for configure --keyring-backend string Keyring backend to store your account keys (default "test") + --keyring-dir string The accounts keyring directory (default "/home/runner/.ignite/accounts") --ordered Set the channel as ordered -r, --reset Reset the relayer config --source-account string Source Account @@ -602,6 +1267,7 @@ ignite relayer connect [,...] [flags] ``` -h, --help help for connect --keyring-backend string Keyring backend to store your account keys (default "test") + --keyring-dir string The accounts keyring directory (default "/home/runner/.ignite/accounts") ``` **SEE ALSO** @@ -615,9 +1281,60 @@ Scaffold a new blockchain, module, message, query, and more **Synopsis** -Scaffold commands create and modify the source code files to add functionality. +Scaffolding is a quick way to generate code for major pieces of your +application. + +For details on each scaffolding target (chain, module, message, etc.) run the +corresponding command with a "--help" flag, for example, "ignite scaffold chain +--help". + +The Ignite team strongly recommends committing the code to a version control +system before running scaffolding commands. This will make it easier to see the +changes to the source code as well as undo the command if you've decided to roll +back the changes. + +This blockchain you create with the chain scaffolding command uses the modular +Cosmos SDK framework and imports many standard modules for functionality like +proof of stake, token transfer, inter-blockchain connectivity, governance, and +more. Custom functionality is implemented in modules located by convention in +the "x/" directory. By default, your blockchain comes with an empty custom +module. Use the module scaffolding command to create an additional module. + +An empty custom module doesn't do much, it's basically a container for logic +that is responsible for processing transactions and changing the application +state. Cosmos SDK blockchains work by processing user-submitted signed +transactions, which contain one or more messages. A message contains data that +describes a state transition. A module can be responsible for handling any +number of messages. + +A message scaffolding command will generate the code for handling a new type of +Cosmos SDK message. Message fields describe the state transition that the +message is intended to produce if processed without errors. + +Scaffolding messages is useful to create individual "actions" that your module +can perform. Sometimes, however, you want your blockchain to have the +functionality to create, read, update and delete (CRUD) instances of a +particular type. Depending on how you want to store the data there are three +commands that scaffold CRUD functionality for a type: list, map, and single. +These commands create four messages (one for each CRUD action), and the logic to +add, delete, and fetch the data from the store. If you want to scaffold only the +logic, for example, you've decided to scaffold messages separately, you can do +that as well with the "--no-message" flag. + +Reading data from a blockchain happens with a help of queries. Similar to how +you can scaffold messages to write data, you can scaffold queries to read the +data back from your blockchain application. + +You can also scaffold a type, which just produces a new protocol buffer file +with a proto message description. Note that proto messages produce (and +correspond with) Go types whereas Cosmos SDK messages correspond to proto "rpc" +in the "Msg" service. + +If you're building an application with custom IBC logic, you might need to +scaffold IBC packets. An IBC packet represents the data sent from one blockchain +to another. You can only scaffold IBC packets in IBC-enabled modules scaffolded +with an "--ibc" flag. Note that the default module is not IBC-enabled. -CRUD stands for "create, read, update, delete". **Options** @@ -657,7 +1374,7 @@ ignite scaffold band [queryName] --module [moduleName] [flags] **Options** ``` - --clear-cache Clear the build cache (advanced) + --clear-cache clear the build cache (advanced) -h, --help help for band --module string IBC Module to add the packet into -p, --path string path of the app (default ".") @@ -678,30 +1395,45 @@ Fully-featured Cosmos SDK blockchain Create a new application-specific Cosmos SDK blockchain. -For example, the following command will create a blockchain called "hello" in the "hello/" directory: +For example, the following command will create a blockchain called "hello" in +the "hello/" directory: -```bash -ignite scaffold chain hello -``` + ignite scaffold chain hello -A project name can be a simple name or a URL. The name will be used as the Go module path for the project. Examples of project names: +A project name can be a simple name or a URL. The name will be used as the Go +module path for the project. Examples of project names: - - ignite scaffold chain foo - - ignite scaffold chain foo/bar - - ignite scaffold chain example.org/foo - - ignite scaffold chain github.com/username/foo + ignite scaffold chain foo + ignite scaffold chain foo/bar + ignite scaffold chain example.org/foo + ignite scaffold chain github.com/username/foo -A new directory with source code files will be created in the current directory. To use a different path use the "--path" flag. - -Most of the logic of your blockchain is written in custom modules. Each module effectively encapsulates an independent piece of functionality. Following the Cosmos SDK convention, custom modules are stored inside the "x/" directory. By default, Ignite creates a module with a name that matches the name of the project. To create a blockchain without a default module use the "--no-module" flag. Additional modules can be added after a project is created with "ignite scaffold module" command. - -Account addresses on Cosmos SDK-based blockchains have string prefixes. For example, the Cosmos Hub blockchain uses the default "cosmos" prefix, so that addresses look like this: "cosmos12fjzdtqfrrve7zyg9sv8j25azw2ua6tvu07ypf". To use a custom address prefix use the "--address-prefix" flag. For example: +A new directory with source code files will be created in the current directory. +To use a different path use the "--path" flag. + +Most of the logic of your blockchain is written in custom modules. Each module +effectively encapsulates an independent piece of functionality. Following the +Cosmos SDK convention, custom modules are stored inside the "x/" directory. By +default, Ignite creates a module with a name that matches the name of the +project. To create a blockchain without a default module use the "--no-module" +flag. Additional modules can be added after a project is created with "ignite +scaffold module" command. + +Account addresses on Cosmos SDK-based blockchains have string prefixes. For +example, the Cosmos Hub blockchain uses the default "cosmos" prefix, so that +addresses look like this: "cosmos12fjzdtqfrrve7zyg9sv8j25azw2ua6tvu07ypf". To +use a custom address prefix use the "--address-prefix" flag. For example: ignite scaffold chain foo --address-prefix bar -By default when compiling a blockchain's source code Ignite creates a cache to speed up the build process. To clear the cache when building a blockchain use the "--clear-cache" flag. It is very unlikely you will ever need to use this flag. +By default when compiling a blockchain's source code Ignite creates a cache to +speed up the build process. To clear the cache when building a blockchain use +the "--clear-cache" flag. It is very unlikely you will ever need to use this +flag. + +The blockchain is using the Cosmos SDK modular blockchain framework. Learn more +about Cosmos SDK on https://docs.cosmos.network -The blockchain is using the Cosmos SDK modular blockchain framework. Learn more about Cosmos SDK on https://docs.cosmos.network ``` ignite scaffold chain [name] [flags] @@ -711,7 +1443,7 @@ ignite scaffold chain [name] [flags] ``` --address-prefix string Account address prefix (default "cosmos") - --clear-cache Clear the build cache (advanced) + --clear-cache clear the build cache (advanced) -h, --help help for chain --no-module Create a project without a default module -p, --path string Create a project in a specific path (default ".") @@ -747,6 +1479,84 @@ ignite scaffold flutter [flags] CRUD for data stored as an array +**Synopsis** + +The "list" scaffolding command is used to generate files that implement the +logic for storing and interacting with data stored as a list in the blockchain +state. + +The command accepts a NAME argument that will be used as the name of a new type +of data. It also accepts a list of FIELDs that describe the type. + +The interaction with the data follows the create, read, updated, and delete +(CRUD) pattern. For each type three Cosmos SDK messages are defined for writing +data to the blockchain: MsgCreate{Name}, MsgUpdate{Name}, MsgDelete{Name}. For +reading data two queries are defined: {Name} and {Name}All. The type, messages, +and queries are defined in the "proto/" directory as protocol buffer messages. +Messages and queries are mounted in the "Msg" and "Query" services respectively. + +When messages are handled, the appropriate keeper methods are called. By +convention, the methods are defined in +"x/{moduleName}/keeper/msg_server_{name}.go". Helpful methods for getting, +setting, removing, and appending are defined in the same "keeper" package in +"{name}.go". + +The "list" command essentially allows you to define a new type of data and +provides the logic to create, read, update, and delete instances of the type. +For example, let's review a command that generates the code to handle a list of +posts and each post has "title" and "body" fields: + + ignite scaffold list post title body + +This provides you with a "Post" type, MsgCreatePost, MsgUpdatePost, +MsgDeletePost and two queries: Post and PostAll. The compiled CLI, let's say the +binary is "blogd" and the module is "blog", has commands to query the chain (see +"blogd q blog") and broadcast transactions with the messages above (see "blogd +tx blog"). + +The code generated with the list command is meant to be edited and tailored to +your application needs. Consider the code to be a "skeleton" for the actual +business logic you will implement next. + +By default, all fields are assumed to be strings. If you want a field of a +different type, you can specify it after a colon ":". The following types are +supported: string, bool, int, uint, coin, array.string, array.int, array.uint, +array.coin. An example of using custom types: + + ignite scaffold list pool amount:coin tags:array.string height:int + +Ignite also supports custom types: + + ignite scaffold list product-details name description + + ignite scaffold list product price:coin details:ProductDetails + +In the example above the "ProductDetails" type was defined first, and then used +as a custom type for the "details" field. Ignite doesn't support arrays of +custom types yet. + +By default the code will be scaffolded in the module that matches your project's +name. If you have several modules in your project, you might want to specify a +different module: + + ignite scaffold list post title body --module blog + +By default, each message comes with a "creator" field that represents the +address of the transaction signer. You can customize the name of this field with +a flag: + + ignite scaffold list post title body --signer author + +It's possible to scaffold just the getter/setter logic without the CRUD +messages. This is useful when you want the methods to handle a type, but would +like to scaffold messages manually. Use a flag to skip message scaffolding: + + ignite scaffold list post title body --no-message + +The "creator" field is not generated if a list is scaffolded with the +"--no-message" flag. + + ``` ignite scaffold list NAME [field]... [flags] ``` @@ -754,7 +1564,7 @@ ignite scaffold list NAME [field]... [flags] **Options** ``` - --clear-cache Clear the build cache (advanced) + --clear-cache clear the build cache (advanced) -h, --help help for list --module string Module to add into. Default is app's main module --no-message Disable CRUD interaction messages scaffolding @@ -773,6 +1583,49 @@ ignite scaffold list NAME [field]... [flags] CRUD for data stored as key-value pairs +**Synopsis** + +The "map" scaffolding command is used to generate files that implement the logic +for storing and interacting with data stored as key-value pairs (or a +dictionary) in the blockchain state. + +The "map" command is very similar to "ignite scaffold list" with the main +difference in how values are indexed. With "list" values are indexed by an +incrementing integer, whereas "list" values are indexed by a user-provided value +(or multiple values). + +Let's use the same blog post example: + + ignite scaffold map post title body + +This command scaffolds a "Post" type and CRUD functionality to create, read, +updated, and delete posts. However, when creating a new post with your chain's +binary (or by submitting a transaction through the chain's API) you will be +required to provide an "index": + + blogd tx blog create-post [index] [title] [body] + blogd tx blog create-post hello "My first post" "This is the body" + +This command will create a post and store it in the blockchain's state under the +"hello" index. You will be able to fetch back the value of the post by querying +for the "hello" key. + + blogd q blog show-post hello + +To customize the index, use the "--index" flag. Multiple indices can be +provided, which simplifies querying values. For example: + + ignite scaffold map product price desc --index category,guid + +With this command, you would get a "Product" value indexed by both a category +and a GUID (globally unique ID). This will let you programmatically fetch +product values that have the same category but are using different GUIDs. + +Since the behavior of "list" and "map" scaffolding is very similar, you can use +the "--no-message", "--module", "--signer" flags as well as the colon syntax for +custom types. + + ``` ignite scaffold map NAME [field]... [flags] ``` @@ -780,7 +1633,7 @@ ignite scaffold map NAME [field]... [flags] **Options** ``` - --clear-cache Clear the build cache (advanced) + --clear-cache clear the build cache (advanced) -h, --help help for map --index strings fields that index the value (default [index]) --module string Module to add into. Default is app's main module @@ -800,6 +1653,53 @@ ignite scaffold map NAME [field]... [flags] Message to perform state transition on the blockchain +**Synopsis** + +Message scaffolding is useful for quickly adding functionality to your +blockchain to handle specific Cosmos SDK messages. + +Messages are objects whose end goal is to trigger state transitions on the +blockchain. A message is a container for fields of data that affect how the +blockchain's state will change. You can think of messages as "actions" that a +user can perform. + +For example, the bank module has a "Send" message for token transfers between +accounts. The send message has three fields: from address (sender), to address +(recipient), and a token amount. When this message is successfully processed, +the token amount will be deducted from the sender's account and added to the +recipient's account. + +Ignite's message scaffolding lets you create new types of messages and add them +to your chain. For example: + + ignite scaffold message add-pool amount:coins denom active:bool --module dex + +The command above will create a new message MsgAddPool with three fields: amount +(in tokens), denom (a string), and active (a boolean). The message will be added +to the "dex" module. + +By default, the message is defined as a proto message in the +"proto/{module}/tx.proto" and registered in the "Msg" service. A CLI command to +create and broadcast a transaction with MsgAddPool is created in the module's +"cli" package. Additionally, Ignite scaffolds a message constructor and the code +to satisfy the sdk.Msg interface and register the message in the module. + +Most importantly in the "keeper" package Ignite scaffolds an "AddPool" function. +Inside this function, you can implement message handling logic. + +When successfully processed a message can return data. Use the —response flag to +specify response fields and their types. For example + + ignite scaffold message create-post title body --response id:int,title + +The command above will scaffold MsgCreatePost which returns both an ID (an +integer) and a title (a string). + +Message scaffolding follows the rules as "ignite scaffold list/map/single" and +supports fields with standard and custom types. See "ignite scaffold list —help" +for details. + + ``` ignite scaffold message [name] [field1] [field2] ... [flags] ``` @@ -807,7 +1707,7 @@ ignite scaffold message [name] [field1] [field2] ... [flags] **Options** ``` - --clear-cache Clear the build cache (advanced) + --clear-cache clear the build cache (advanced) -d, --desc string Description of the command -h, --help help for message --module string Module to add the message into. Default: app's main module @@ -829,7 +1729,65 @@ Scaffold a Cosmos SDK module **Synopsis** -Scaffold a new Cosmos SDK module in the `x` directory +Scaffold a new Cosmos SDK module. + +Cosmos SDK is a modular framework and each independent piece of functionality is +implemented in a separate module. By default your blockchain imports a set of +standard Cosmos SDK modules. To implement custom functionality of your +blockchain, scaffold a module and implement the logic of your application. + +This command does the following: + +* Creates a directory with module's protocol buffer files in "proto/" +* Creates a directory with module's boilerplate Go code in "x/" +* Imports the newly created module by modifying "app/app.go" +* Creates a file in "testutil/keeper/" that contains logic to create a keeper + for testing purposes + +This command will proceed with module scaffolding even if "app/app.go" doesn't +have the required default placeholders. If the placeholders are missing, you +will need to modify "app/app.go" manually to import the module. If you want the +command to fail if it can't import the module, use the "--require-registration" +flag. + +To scaffold an IBC-enabled module use the "--ibc" flag. An IBC-enabled module is +like a regular module with the addition of IBC-specific logic and placeholders +to scaffold IBC packets with "ignite scaffold packet". + +A module can depend on one or more other modules and import their keeper +methods. To scaffold a module with a dependency use the "--dep" flag + +For example, your new custom module "foo" might have functionality that requires +sending tokens between accounts. The method for sending tokens is a defined in +the "bank"'s module keeper. You can scaffold a "foo" module with the dependency +on "bank" with the following command: + + ignite scaffold module foo --dep bank + +You can then define which methods you want to import from the "bank" keeper in +"expected_keepers.go". + +You can also scaffold a module with a list of dependencies that can include both +standard and custom modules (provided they exist): + + ignite scaffold module bar --dep foo,mint,account + +Note: the "--dep" flag doesn't install third-party modules into your +application, it just generates extra code that specifies which existing modules +your new custom module depends on. + +A Cosmos SDK module can have parameters (or "params"). Params are values that +can be set at the genesis of the blockchain and can be modified while the +blockchain is running. An example of a param is "Inflation rate change" of the +"mint" module. A module can be scaffolded with params using the "--params" flag +that accepts a list of param names. By default params are of type "string", but +you can specify a type for each param. For example: + + ignite scaffold module foo --params baz:uint,bar:bool + +Refer to Cosmos SDK documentation to learn more about modules, dependencies and +params. + ``` ignite scaffold module [name] [flags] @@ -838,7 +1796,7 @@ ignite scaffold module [name] [flags] **Options** ``` - --clear-cache Clear the build cache (advanced) + --clear-cache clear the build cache (advanced) --dep strings module dependencies (e.g. --dep account,bank) -h, --help help for module --ibc scaffold an IBC module @@ -870,7 +1828,7 @@ ignite scaffold packet [packetName] [field1] [field2] ... --module [moduleName] ``` --ack strings Custom acknowledgment type (field1,field2,...) - --clear-cache Clear the build cache (advanced) + --clear-cache clear the build cache (advanced) -h, --help help for packet --module string IBC Module to add the packet into --no-message Disable send message scaffolding @@ -895,7 +1853,7 @@ ignite scaffold query [name] [request_field1] [request_field2] ... [flags] **Options** ``` - --clear-cache Clear the build cache (advanced) + --clear-cache clear the build cache (advanced) -d, --desc string Description of the command -h, --help help for query --module string Module to add the query into. Default: app's main module @@ -921,7 +1879,7 @@ ignite scaffold single NAME [field]... [flags] **Options** ``` - --clear-cache Clear the build cache (advanced) + --clear-cache clear the build cache (advanced) -h, --help help for single --module string Module to add into. Default is app's main module --no-message Disable CRUD interaction messages scaffolding @@ -947,7 +1905,7 @@ ignite scaffold type NAME [field]... [flags] **Options** ``` - --clear-cache Clear the build cache (advanced) + --clear-cache clear the build cache (advanced) -h, --help help for type --module string Module to add into. Default is app's main module --no-message Disable CRUD interaction messages scaffolding @@ -996,81 +1954,11 @@ Tools for advanced users **SEE ALSO** * [ignite](#ignite) - Ignite CLI offers everything you need to scaffold, test, build, and launch your blockchain -* [ignite tools completions](#ignite-tools-completions) - Generate completions script * [ignite tools ibc-relayer](#ignite-tools-ibc-relayer) - Typescript implementation of an IBC relayer * [ignite tools ibc-setup](#ignite-tools-ibc-setup) - Collection of commands to quickly setup a relayer * [ignite tools protoc](#ignite-tools-protoc) - Execute the protoc command -## ignite tools completions - -Generate completions script - -**Synopsis** - - The completions command outputs a completion script you can use in your shell. The output script requires - that [bash-completion](https://github.com/scop/bash-completion) is installed and enabled in your - system. Since most Unix-like operating systems come with bash-completion by default, bash-completion - is probably already installed and operational. - -Bash: - - $ source <(ignite tools completions bash) - - To load completions for every new session, run: - - ** Linux ** - $ ignite tools completions bash > /etc/bash_completion.d/ignite - - ** macOS ** - $ ignite tools completions bash > /usr/local/etc/bash_completion.d/ignite - -Zsh: - - If shell completions is not already enabled in your environment, you will need to enable it. You can execute the following once: - - $ echo "autoload -U compinit; compinit" >> ~/.zshrc - - To load completions for each session, execute once: - - $ ignite tools completions zsh > "${fpath[1]}/_ignite" - - You will need to start a new shell for this setup to take effect. - -fish: - - $ ignite tools completions fish | source - - To load completions for each session, execute once: - - $ ignite tools completions fish > ~/.config/fish/completionss/ignite.fish - -PowerShell: - - PS> ignite tools completions powershell | Out-String | Invoke-Expression - - To load completions for every new session, run: - - PS> ignite tools completions powershell > ignite.ps1 - - and source this file from your PowerShell profile. - - -``` -ignite tools completions -``` - -**Options** - -``` - -h, --help help for completions -``` - -**SEE ALSO** - -* [ignite tools](#ignite-tools) - Tools for advanced users - - ## ignite tools ibc-relayer Typescript implementation of an IBC relayer