Additional custom fields

[SkyaTura]

Description of the problem

Some platforms allow quick actions to apply changes on issues/PRs through specific commands written on commit messages.

Solution

Allow custom fields to be created with specific prompts or lists to fulfill some template.

For instance:

? Choose a gitmoji: ✨  - Introduce new features.
? Enter the commit title [24/48]: Add super awesome button
? Enter the commit message:
? Time spent on this issue: 32h
? The issue is complete already (y/N): y

That is a heck of button

If the last fields are filled, the final commit message would have /spent 32h and /request_review appended at the end, adding time-tracking features from GitLab.

This could be used not only for convenience, but also to help enforcing team patterns usage...

Alternatives

Well, just type the full command on the message body... but that is not as cool

Additional context

I think this may be somewhat related to #780, but I chose to create a new one because this concept doesn't exist yet, unlike scopes which is already a feature.

Validations

• Follow our Code of Conduct
• Read the Contributing Guide.
• Check that there isn't already an issue requesting the same feature.

[carloscuesta]

Hey! 👋🏼

I think this is something we may want to explore as part of the cli. If I understood properly the idea would be to allow users defining custom prompts as part of the CLI configuration.

In a way that you can "tailor" the prompts according to your workflow, for things that we don't want to bundle as part of the cli itself.

One potential challenge I see with this, is that by introducing this "flexibility" into the cli, it would open the door for people to break it, since there's no way for us to validate user defined custom prompts.

Also it can be very tricky to know where the "prompt" should be applied (e.g: commit message, commit title etc).

[SkyaTura]

This is what I had in mind.

First, this level of customization, at least for 1st versions, should be done at a "config file" level, to avoid overcomplicating the implementation of the settings.

We could work with a template language and a concept of fields, which at least the "emoji", "title" and "message" must be put in place.

That said, take for example the following config (using handlebars.js):

custom_commit_message:
  additional_fields:
    - type: text
      name: scope
      label: "Insert the scope of the changes"
      required: false
    - type: list
      name: affected
      multiple: true
      required: false
      options:
        - app
        - api
        - value: other
          text: "Something else"
    - type: boolean
      name: request_review
      label: "Is it ready for code review"
    - type: text
      name: issue
      label: "It closes an open issue"
      condition: request_review
      validation: /GM[0-9]{4}/
    - type: number
      name: spent_hours
      label: "How many hours were spent"
      mask: 0h
      required: true
  template: >-
    {{emoji}} {{#if scope.length}}[{{scope}}]{{/if}} {{title}}

    {{message}}
    
    /spent {{spent_hours}}h
    {{#request_review}}
    /fixes {{issue}}
    /request_review
    {{/request_review}}

The input when commit would be:

? Choose a gitmoji: 💥 - Introduce new features.
? Enter the commit title [24/48]: Add super awesome button
? Enter the commit message: This button has many features that will change the whole concept of buttons.
? Enter the scope of the changes: 
? Is it ready for code review (y/N): y
? It closes an open issue: GM2134
? How many hours were spent: 32

The final output:

💥  Add super awesome button

This button has many features that will change the whole concept of buttons.

/spent 32h
/request_review
/fixes GM2134

[carloscuesta]

Hey!

Thanks, that's a good starting point, I think we should somehow integrate the additional input as part of the current configuration that we have:

https://github.com/carloscuesta/gitmoji-cli#config

I'm wondering what would happen with the local configuration as it can be very tricky to setup this via CLI 🤔

[SkyaTura]

Through an cli UI would be really tricky, in deed.

I used an YAML because I was lazy to write JSON (or convert it haha), but this could be used within the current config options, both local or global (which I assume it is a file as well).

I think that, to address simple inputs, the format I proposed would be ok.

To more complex templates, an alternative would be using the config to point out a template file to be used as input the same way custom_commit_message.message is set on the example above.

What do you think about that?

---

Also, I didn't checked how is the user inputs are currently implemented yet, so I went a little ambicious proposing that level of complexity to illustrate how it could be useful.

[carloscuesta]

Perhaps we can leave the configuration for this "outside" of the CLI experience 🤔

I think that, to address simple inputs, the format I proposed would be ok.

Yes I agree, we can discuss the format later but something that allows you to customise the inputs taking into account that we're using Inquirer.js behind it.

To more complex templates, an alternative would be using the config to point out a template file to be used as input the same way custom_commit_message.message is set on the example above.

Hmmm, I think relying on external files can be a bit more tricky from a user POV and the cli as well so I would prefer leaving everything under our configuration file.

[vhoyer]

I'm very pro this idea, in fact, if we are gonna support the json format, maybe the template can come in array format?

{
    "template": [
        "{{emoji}} {{#if scope.length}}[{{scope}}]{{/if}} {{title}}",
        "",
        "{{message}}",
        "",
        "/spent {{spent_hours}}h",
        "{{#request_review}}",
        "/fixes {{issue}}",
        "/request_review",
        "{{/request_review}}",
    ],
}