docs(cmd): update commands to ignite cosmos namespace

Author: julienrbrt

ignite/cmd/chain_build.go

@@ -35,21 +35,21 @@ 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
+	ignite cosmos 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
+	ignite cosmos 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
+	ignite cosmos 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
@@ -79,7 +79,7 @@ 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
+	ignite cosmos chain build --release -t linux:amd64 -t darwin:amd64 -t darwin:arm64
 `,
 		Args: cobra.NoArgs,
 		RunE: chainBuildHandler,

ignite/cmd/chain_debug.go

@@ -44,11 +44,11 @@ JSON-RPC or DAP client connections.
 
 To start a debug server use the following flag:
 
-	ignite chain debug --server
+	ignite cosmos chain debug --server
 
 To start a debug server with a custom address use the following flags:
 
-	ignite chain debug --server --server-address 127.0.0.1:30500
+	ignite cosmos chain debug --server --server-address 127.0.0.1:30500
 
 The debug server stops automatically when the client connection is closed.
 `,

ignite/cmd/chain_init.go

@@ -13,10 +13,10 @@ func NewChainInit() *cobra.Command {
 	c := &cobra.Command{
 		Use:   "init",
 		Short: "Initialize your chain",
-		Long: `The init command compiles and installs the binary (like "ignite chain build")
+		Long: `The init command compiles and installs the binary (like "ignite cosmos 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".
+validator. To learn how the build process works, refer to "ignite cosmos 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

ignite/cmd/chain_serve.go

@@ -37,9 +37,9 @@ func NewChainServe() *cobra.Command {
 	c := &cobra.Command{
 		Use:   "serve",
 		Short: "Start a blockchain node in development",
-		Long: `The serve command compiles and installs the binary (like "ignite chain build"),
+		Long: `The serve command compiles and installs the binary (like "ignite cosmos 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
+(like "ignite cosmos chain init"), and starts the node locally for development purposes
 with automatic code reloading.
 
 Automatic code reloading means Ignite starts watching the project directory.
@@ -52,19 +52,19 @@ 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
+	ignite cosmos 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
+	ignite cosmos 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
+	ignite cosmos 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

ignite/cmd/cmd.go

@@ -248,17 +248,17 @@ func deprecated() []*cobra.Command {
 		{
 			Use:        "build",
 			Hidden:     true,
-			Deprecated: "use `ignite chain build` instead.",
+			Deprecated: "use `ignite cosmos chain build` instead.",
 		},
 		{
 			Use:        "serve",
 			Hidden:     true,
-			Deprecated: "use `ignite chain serve` instead.",
+			Deprecated: "use `ignite cosmos chain serve` instead.",
 		},
 		{
 			Use:        "faucet",
 			Hidden:     true,
-			Deprecated: "use `ignite chain faucet` instead.",
+			Deprecated: "use `ignite cosmos chain faucet` instead.",
 		},
 		{
 			Use:        "node",

ignite/cmd/generate_typescript_client.go

@@ -25,12 +25,12 @@ can customize the output directory in config.yml:
 
 Output can also be customized by using a flag:
 
-	ignite generate ts-client --output new-path
+	ignite cosmos generate ts-client --output new-path
 
 TypeScript client code can be automatically regenerated on reset or source code
 changes when the blockchain is started with a flag:
 
-	ignite chain serve --generate-clients
+	ignite cosmos chain serve --generate-clients
 `,
 		RunE: generateTSClientHandler,
 	}

ignite/cmd/scaffold.go

@@ -30,10 +30,10 @@ const (
 	msgCommitPrompt = "Do you want to proceed without committing your saved changes"
 
 	statusScaffolding      = "Scaffolding..."
-	multipleCoinDisclaimer = `**Disclaimer**  
-The 'coins' and 'dec.coins' argument types require special attention when used in CLI commands. 
-Due to current limitations in the AutoCLI, only one variadic (slice) argument is supported per command. 
-If a message contains more than one field of type 'coins' or 'dec.coins', only the last one will accept multiple values via the CLI. 
+	multipleCoinDisclaimer = `**Disclaimer**
+The 'coins' and 'dec.coins' argument types require special attention when used in CLI commands.
+Due to current limitations in the AutoCLI, only one variadic (slice) argument is supported per command.
+If a message contains more than one field of type 'coins' or 'dec.coins', only the last one will accept multiple values via the CLI.
 For the best user experience, manual command handling or scaffolding is recommended when working with messages containing multiple 'coins' or 'dec.coins' fields.
 `
 )
@@ -47,8 +47,8 @@ func NewScaffold() *cobra.Command {
 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".
+corresponding command with a "--help" flag, for example, "ignite cosmos
+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

ignite/cmd/scaffold_chain.go

@@ -25,7 +25,7 @@ const (
 👉 Get started with the following commands:
 
  %% cd %[1]v
- %% ignite chain serve
+ %% ignite cosmos chain serve
 
 Documentation: https://docs.ignite.com
 `
@@ -41,16 +41,16 @@ func NewScaffoldChain() *cobra.Command {
 For example, the following command will create a blockchain called "hello" in
 the "hello/" directory:
 
-	ignite scaffold chain hello
+	ignite cosmos 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:
 
-	ignite scaffold chain foo
-	ignite scaffold chain foo/bar
-	ignite scaffold chain example.org/foo
-	ignite scaffold chain github.com/username/foo
-		
+	ignite cosmos scaffold chain foo
+	ignite cosmos scaffold chain foo/bar
+	ignite cosmos scaffold chain example.org/foo
+	ignite cosmos 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.
 
@@ -59,15 +59,15 @@ 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.
+flag. Additional modules can be added after a project is created with the
+"ignite cosmos 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
+	ignite cosmos 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

ignite/cmd/scaffold_configs.go

@@ -19,10 +19,10 @@ func NewScaffoldConfigs() *cobra.Command {
 
 A Cosmos SDK module can have configurations. An example of a config is "address prefix" of the
 "auth" module. A config can be scaffolded into a module using the "--module-configs" into
-the scaffold module command or using the "scaffold configs" command. By default 
+the scaffold module command or using the "scaffold configs" command. By default
 configs are of type "string", but you can specify a type for each config. For example:
 
-	ignite scaffold configs foo baz:uint bar:bool
+	ignite cosmos scaffold configs foo baz:uint bar:bool
 
 Refer to Cosmos SDK documentation to learn more about modules, dependencies and
 configs.

ignite/cmd/scaffold_list.go

@@ -36,7 +36,7 @@ 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
+	ignite cosmos 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
@@ -53,17 +53,17 @@ 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 field types:
 
-	ignite scaffold list pool amount:coin tags:array.string height:int
+	ignite cosmos scaffold list pool amount:coin tags:array.string height:int
 
-For detailed type information use ignite scaffold type --help
+For detailed type information use ignite cosmos scaffold type --help
 
 "Index" indicates whether the type can be used as an index in
-"ignite scaffold map".
+"ignite cosmos scaffold map".
 
 Ignite also supports custom types:
 
-	ignite scaffold list product-details name desc
-	ignite scaffold list product price:coin details:ProductDetails
+	ignite cosmos scaffold list product-details name desc
+	ignite cosmos 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.
@@ -76,19 +76,19 @@ 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
+	ignite cosmos 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
+	ignite cosmos 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
+	ignite cosmos scaffold list post title body --no-message
 
 The "creator" field is not generated if a list is scaffolded with the
 "--no-message" flag.