Document suggested layout for subcommands (#1930)

Signed-off-by: Luiz Carvalho <lucarval@redhat.com>
This commit is contained in:
Luiz Carvalho 2023-03-16 21:03:29 -04:00 committed by GitHub
parent b197a24504
commit c8a20a16ba
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 31 additions and 0 deletions

View File

@ -188,6 +188,37 @@ var versionCmd = &cobra.Command{
} }
``` ```
### Organizing subcommands
A command may have subcommands which in turn may have other subcommands. This is achieved by using
`AddCommand`. In some cases, especially in larger applications, each subcommand may be defined in
its own go package.
The suggested approach is for the parent command to use `AddCommand` to add its most immediate
subcommands. For example, consider the following directory structure:
```text
├── cmd
│   ├── root.go
│   └── sub1
│   ├── sub1.go
│   └── sub2
│   ├── leafA.go
│   ├── leafB.go
│   └── sub2.go
└── main.go
```
In this case:
* The `init` function of `root.go` adds the command defined in `sub1.go` to the root command.
* The `init` function of `sub1.go` adds the command defined in `sub2.go` to the sub1 command.
* The `init` function of `sub2.go` adds the commands defined in `leafA.go` and `leafB.go` to the
sub2 command.
This approach ensures the subcommands are always included at compile time while avoiding cyclic
references.
### Returning and handling errors ### Returning and handling errors
If you wish to return an error to the caller of a command, `RunE` can be used. If you wish to return an error to the caller of a command, `RunE` can be used.