Add a `serverelss function <action>` command

This is a Feature Proposal

Description

To help keep parity with the new serverless plugin <action> command we should introduce a serverless function <action> command. There was consensus that the grouping of actions under a specific <object> makes more sense and is easier to understand. https://github.com/serverless/serverless/pull/4046

The first commands that would be available are the ones that already exist.

serverless function deploy
serverless function rollback

However, this will leave room for adding such commands as…

serverless function install
serverless function publish
...

[HyperBrain]

Furthermore what about aliases which might overlap / end in an infinite loop (or smth. along those lines)? Is the alias always command:lifecycleEvent? What about entrypoints?

There can be multiple cases for that - here with some solutions:

• An alias has already been registered by a previous plugin (2 plugins register the same alias) ⇨ The second registration should fail to tell the plugin author that the alias is already in use. This will automatically prioritize core plugins because they are loaded first. So 3rd party plugins cannot use any alias used by the core.
• Multiple plugins add an alias that share common paths (like function:deploy and function:rollback) ⇨ The common path would be a shared alias command (here: function) and the subcommands are aliases to the resp. original commands. This allows to create “bucket” functions that are only virtual hosts for aliases. ⇨ It is a design decision if the core defines virtual buckets upfront or lets the system dynamically compose them when aliases are created. ⇨ 3rd party plugins must not alias a common path. This should lead to en error (e.g. plugin X registers “function” as alias). Can be checked during plugin loading. However, aliasing beneath an existing alias is allowed (e.g. to extend a command or alias with subcommands).
• Circular aliases/commands ⇨ I believe that this can be catched in pluginManager in a deterministic way. PluginManager has to check for circular aliases and bail out. As aliases are a static command definition this will definitly eliminate any risk of circular aliases.
• Entrypoints ⇨ I’m not sure if aliases can be non-visible entrypoints at all. Everything aliased should be public, so it is also callable from within another plugin via spawn() or run(). So aliases are public commands in any case, and can themselves never be entrypoints. ⇨ Entrypoints can be used as a “move” of an command. E.g. to expose deploy:function only as function:deploy (a move!) entrypoints can help. You just have to declare the old deploy:function as entrypoint, so that it is not accessible from the CLI anymore, but declare an alias for it function:deploy. This will automatically make the old command hidden, but the new command public.
• Lifecycle events ⇨ The triggered lifecycle events are always the events from the original command. ⇨ Aliases only start the original commands internally

Only downside could be that it could be harder to reason about the code execution flow.

Slightly disagree here, as aliases do not invent/implement their own lifecycles but start the original command’s lifecycles. To have a clear overview of aliases I can extend my lifecycle cheat sheet to show the aliases too. So any plugin author has all information at hand. Also documenting the behavior should not be very complex.

[HyperBrain]

I rethought a bit over this again. Now I’m pretty sure that these kind of command changes can indeed be done in a non-breaking way. The key is to introduce command aliases, i.e. existing commands could define aliases which just invoke the existing commands without the need to implement the alias command at all. This would be the most compatible and non-breaking approach and will allow to make commands available under different paths and commands,

The definition of such an alias would be quite simple:

// lib/deploy/deploy.js
...
this.commands = {
  deploy: {
    ...
    commands: {
      function: {
        usage: 'Deploy a single function from the service',
        lifecycleEvents: [ ... ],
        aliases: [
          'function:deploy'
        ]
      }
    }
  }
}
...

The alias command implementation is easy and local to pluginManager, i.e. when loading plugins and their commands, the pluginManager would also parse the aliases array and setup the alias commands in the commands collection with their hooks just being duplicates of the original command’s hook. This would be stable and non-breaking - and best of all, also plugins can integrate with this mechanism. The need to discuss risky command movements or changes will be eliminated completely then and all command changes will be non-breaking in nature.

The Serverless help could be changed to display commands along with their aliases or only aliases, whatever makes more sense.

@pmuens @eahefnawy What do you think about this approach? I think I can get a PR up and running in just a few days (hours?) as it is really easy.