A venom-free generator for cobra applications.

go get -u github.com/oncilla/boa/cmd/boa

If you prefer using docker instead:

WORKDIR=$(pwd)/path/to/application
docker run \
    -v $WORKDIR/:/workdir \
    --user "$(id -u):$(id -g)" \
    docker.pkg.github.com/oncilla/boa/boa:latest

boa proposes a different layout than what cobra proposes as a typical structure.

The commands all live in main package, alongside the main function.

cmd/my-app/
├── my-app.go      # main function
├── completion.go  # completion command
└── version.go     # version command

The commands should be fairly slim and only take care of checking flags and initializing the application. Business logic should not go here, but move to a separate package to ensure it is decoupled from the CLI, reusable and has no access to global values.

Where you put it is up to you, just try to have the main package as slim as possible.

With boa, your project can have one or multiple cobra based applications. The simplest approach is to have the main package in the project root.

boa init my-app

This creates a runnable cobra application skeleton. Try it out with:

go run *.go --help

The completion and version are created by default, to showcase how a boa style application can look like.

If you want to support multiple cobra applications in your project, or want to keep the root directory clean, you can create the application in a sub-directory:

boa init --path cmd/my-app my-app

To add a command, simply run the add command:

boa add greet --flags name:string,age:int

If you have provided a path before, make sure to provide the same path again, or navigate to the corresponding main package first.

This command creates new file called greet.go with a license header and a cobra command generation function.

func newGreet(pather CommandPather) *cobra.Command {
        var flags struct {
                name string
                age  int
        }

        var cmd = &cobra.Command{
                Use:     "greet <arg>",
                Short:   "greet does amazing work!",
                Example: fmt.Sprintf("  %[1]s greet --sample", pather.CommandPath()),
                RunE: func(cmd *cobra.Command, args []string) error {
                        // Add basic sanity checks, where the usage help message should be
                        // printed on error, before this line. After this line, the usage
                        // message is no longer printed on error.
                        cmd.SilenceUsage = true

                        // TODO: Amazing work goes here!
                        return nil
                },
        }

        cmd.Flags().StringVar(&flags.name, "name", "", "name description")
        cmd.Flags().IntVar(&flags.age, "age", 0, "age description")
        return cmd
}

Boa suggests to use the SilenceErrors and SilenceUsage. For more information, see: spf13/cobra#340 (comment)

You now need to register the command with its parent. For the sake of this example, it is simply the root command. Update my-app.go with:

    cmd.AddCommand(
        newCompletion(cmd),
        newGreet(cmd),
        newVersion(cmd),
    )

That's it, the new command is now registered and can already be used:

$ go run *.go greet --help
greet does amazing work!

Usage:
  my-app greet <arg> [flags]

Examples:
  my-app greet --sample

Flags:
      --age int       age description
  -h, --help          help for greet
      --name string   name description

The cobra library is an amazing and powerful toolkit for creating command line applications. However, the example projects display some drawbacks that boa tries to improve upon.

The proposed rigid directory structure in the examples and the generator go against the commonly used patterns how applications are structured nowadays.

boa proposes to have all commands in the same directory. The key here is, that the main package should only be used for initialization and very simple tasks. Bigger business logic should live in a separate package, ensuring that it is reusable, and decoupled from the CLI interface.

Commands are proposed to be registered inside an init function. Essentially forcing global state, and making it hard for commands to be tested.

With the approach proposed by boa, testing a command is as simple as:

func TestMyCommand(t *testing.T) {
    cmd := newMyCommand(boa.Pather(""))
    cmd.SetArgs([]string{"--my", "args"})
    err := cmd.Execute()
    if err != nil {
        t.Fail()
    }
}

Flags are proposed to be package global variables and registered in the init function. This can lead to code that is full of surprises, as package globals taint logic very easily if you do not take care.

With the approach proposed by boa, each instance of a command has its own set of flags, and there is no way for other components to access them directly.