Support multiple groups for a command

[matt-gadd]

Currently a command can only provide for a single group and that group is decided by part of its package name ie dojo-cli-{groupname}-{command}.

it would be nice if in the command interface you can specify multiple groups or aliases. This is needed to support the dev task, which essentially desugars to the build task with some different arguments.

[jdonaghue]

So I have implemented a new interface that looks like this:

export interface Alias {
    name: string;
    description?: string;
    register?(helper: Helper): Yargs;
}

and the Command interface will have a new optional property that looks like this:

alias?: Alias[]|Alias;

In loadCommands I will consult this new alias property and associate the command for each alias provided. This means that in registerCommands we will still use the main register method for the main group (the one obtained from the package name), but will additionally have to, for each alias, run the alias specific register or the main register if there isn't one. Finally, we will do a similar thing with descriptions as we may want each alias to have its own description.

If everyone agrees with this, I would like to have the help PR #85 to land first so that we reduce conflicts with registering options for help

[tomdye]

@jdonaghue I think this is the right direction but having a register for it is misleading as it's not going to have it's own run function, plus we need to have the ability to provide hardcoded options. I believe we need to have an interface like this:

export interface Alias {
   name: string;
   description: string;
   options: AliasOption[]
} 

export interface AliasOption {
   option: string;
   value?: (string | boolean | number)[]
}

With that in mind, if for example dojo dev aliased dojo build -w (which it likely will), we would not want to see the -w option when we run dojo dev -h, only the remaining -p option that dojo build specifies.

As an example of the above, the dojo dev alias would be along the lines of:

alias: [
   {
      name: 'dev',
      description: 'start dev server',
      options: [{
         option: 'w'
      }]
   }
]

[jdonaghue]

I think this makes a lot of sense @tomdye. It would be good to land #85 first as some of the changes to the registerCommand module needed for that ticket will be needed for this ticket as well. The reason those two projects (cli-create-app and cli-build) are failing CI is because they depend on the changes in #85 to be landed so they can pull the OptionsHelper type correctly from interfaces.

[jdonaghue]

@tomdye I think I might actually just rebase this PR against the PR for #85 so that I can get this one written as I think #85 is close enough now that not much will change in terms of signatures etc.

[tomdye]

Looks like this isn't fully working.

The alias registers and the help drops off the specified alias options, but the command does not appear to run with the alias options.

Tested by adding following command config to @dojo/cli-build-webpack

alias: {
        name: 'dev',
        description: 'Run a dev server with watch',
        options: [
            { option: 'w' }
        ]
    }

Would expect this to run webpack in watch mode, but it does not.

[rorticus]

Looks like this is working, but its kind of confusing to use. The build command is expecting watch instead of w, and an option value is also required.

There is a PR, https://github.com/dojo/cli/pull/126 , to make value required on all alias options so it is not left to chance.