Validator to ensure standard of commands

[ankithans]

related to issue #58

[ankithans]

First Solution

• One obvious solution is to create a type with cobra command options and pass that object into the command.
• Create a validator function to validate that Options type, validate before passing into cobra command

We can ease this for developers by creating code generator

type options struct {
	Use   string
	Short string
	Long  string
}

func validateOptions(opts options) error {
	if len(opts.Short) <= 2 {
		return fmt.Errorf("length of short should be atleast greater than 2")
	}
	if len(opts.Long) <= 5 {
		return fmt.Errorf("length of long should be atleast greater than 5")
	}

	return nil
}

// main
testOpts := &options{
		Use:   "root",
		Short: "r",
		Long:  "root the long string as it should be long so let's test it!",
	}

	err := validateOptions(*testOpts)
	if err != nil {
		panic(err)
	}

	cmd := &cobra.Command{
		Use:     testOpts.Use,
		Short:   testOpts.Short,
		Long:    testOpts.Long,
	}

[ankithans]

Second Solution WIP

https://github.com/ankithans/cobra-linter
writing a custom linter for validation of certain options using this

[ankithans]

Wrote a basic linter which restricts the length of Command attributes.
https://github.com/ankithans/cobra-linter/blob/main/main.go#L33

cmd := &cobra.Command{
		Use:     "E",
		Short:   "The Short Description",
		Long:    "This is long description of the command. As you can see it is so long",
		Example: "I have an example",
	}

	cmd := &cobra.Command{
		Use:     "Example",
		Short:   "The Short Description",
		Long:    "wsw",
		Example: "I have an example",
	}

[ankithans]

I think we can control the things what we want by writing linter. WDYT, which way should we choose?
cc: @wtrocki @namit-chandwani @ mentors @aerogear/charmil-core

[wtrocki]

@ankithans you went far ahead with this with both approaches.
As in the comment in the issue - do we need to write our own linter? How about using golang-lint?

See: https://golangci-lint.run/contributing/new-linters/

As for the approach - we kinda need static analysis rather than code analysis - unless we can think of some clever way to do it at runtime
without calling that code every time command is executed.

As for the AST processor. I do not think we need to go that far as we not going to actually validate golang codebase but can simply operate on cobra structures. (that will be an argument against using golang cli lint)

First we need to define set of linting rules we want to apply:

• Command has examples and Sh
• ort and Long description
• Each argument has a description
• Command has long and short description defined
• Command uses single positional argument (no multiple positional arguments) etc.

I think we need also simplicity of defining linting rules as well. So if charmil integrator has some rule on cobra command structure
it can be written by following docs.

@aerogear/charmil-core