Open mloskot opened 11 months ago
(Copying myself from https://github.com/spf13/cobra/issues/1059#issuecomment-1855063174)
Interestingly, the user_guide.md displays how to organise subcomands in folders but does or could cobra-cli support it?
The current behavior is good, it is useful for the common case of single package command. I think the missing part is to support also the hierarchical layout when initializing a project or adding a command.
I can think of 2 ways to solve this:
Adding a child command as a package:
cobra-cli add --package foo
Will create:
cmd/
root.go
foo/
foo.go
Adding a sub command of foo:
cobra-cli add --parent foo bar
Will create:
cmd/
root.go
foo/
foo.go
bar.go
Adding a sub package for foo:
cobra-cli add --package --parent foo bar
cmd/
root.go
foo/
foo.go
bar/
bar.go
Add an option the the .cobra.yaml to use single package or multi-package layout. This will make it easier to have consistent initialization in the entire project.
Example yaml for single package (default):
layout: single-package
With this child commands are created in the same package as root and add the child command to the root command in the child init().
Example yaml for multi-package layout (new):
layout: multi-package
With this child command is created in a new package and parent init() is changed to add the child command.
This does not solve he issue of adding a leaf command in a sub package, in this case we most likely want to keep the leaf file in the parent package.
I think the missing part is to support also the hierarchical layout when initializing a project or adding a command.
Yes, I think so. Yesterday I found this video where the author presents a simple semi-manual workaround how to use Cobra CLI and maintain folder-based structure of commands. Here is the specific moment linked How to write beautiful Golang CLI
This is transfer of @fanux's https://github.com/spf13/cobra/issues/1059 as suggested there by @johnSchnake
cobra generates subcommand
user
in the same dir of its parent dir, it not very nice.If I add a command
user
this user command is notcreate
subcommand:So I think,
create
subcommand in a sub dir is better, like this:This will not conflict