Conventional Commit Creator

This CLI application assists you in creating commit messages that are conform to the conventional commit style. It will ask for type, scope, description, body and issue id.

Features:

⭐ format of the commit message can be fully customized
⭐ different templates for your repositories based on Git remote url
⭐ issue id can be inserted in up to three places of a commit message

Install & usage

Install this package globally.

npm install -g @4s1/conventional-commit-creator

Inside your repository run Conventional Commit Creator.

conventional-commit-creator
# or just
ccc

Configure commit message templates

The configuration is stored in ~/.config/conventional-commit-creator/config.json.

The default template look like the following json:

{
  "$schema": "https://www.4s1.de/conventional-commit-creator/schema.json",
  "version": 1,
  "templates": [
    {
      "name": "Default",
      "regex": ".*",
      "pattern": "{type}{scope}: {description}{issue}{body}",

      "pre_type": "",
      "post_type": "",
      "pre_scope": "(",
      "post_scope": ")",
      "pre_description": "",
      "post_description": "",
      "pre_body": "\n\n",
      "post_body": "",

      "pre_issue": " (#",
      "post_issue": ")",
      "pre_issue2": "",
      "post_issue2": "",
      "pre_issue3": "",
      "post_issue3": ""
    }
  ]
}

and will create the following commit message:

--- your input --------------------------

type: chore
scope: foo
description: some description
body: Lorem ipsum dolor sit amet.
issue: 42

--- commit message result ---------------

chore(foo): some description (#42)

Lorem ipsum dolor sit amet.

The pre and post texts are only inserted if a matching middle part has also been entered.

Now let's look at another more complex variant.

We take the configuration from above, remove all empty strings (missing settings are replaced by empty strings) and add another template that should apply to all GitHub projects (see regex).

{
  "$schema": "https://www.4s1.de/conventional-commit-creator/schema.json",
  "version": 1,
  "templates": [
    {
      "name": "Default",
      "regex": ".*",
      "pattern": "{type}{scope}: {description}{issue}{body}",
      "pre_scope": "(",
      "post_scope": ")",
      "pre_body": "\n\n",
      "pre_issue": " (#",
      "post_issue": ")"
    },
    {
      "name": "GitHub Project",
      "regex": "^.*github.*$",
      "pattern": "{type}{scope}: {description}{body}{issue}{issue2}{issue3}",
      "pre_scope": "(",
      "post_scope": ")",
      "pre_body": "\n\n",
      "pre_issue": "\n\nRefs: #",
      "pre_issue2": " | [refs #",
      "post_issue2": "]",
      "pre_issue3": " | REDMINE-",
      "post_issue3": ""
    }
  ]
}

This will result in the following commit example:

--- your input --------------------------

type: refactor
scope: -
description: foobar
body: Hallo \n world
issue: 42

--- commit message result ---------------

refactor: foobar

Hallo
world

Refs: #42 | [refs #42] | REDMINE-42

or without issue id

--- your input --------------------------

type: refactor
scope: -
description: foobar
body: Hallo \n world
issue: -

--- commit message result ---------------

refactor: foobar

Hallo
world

Checking the Git remote url via regular expression is done in the order the templates were specified from top to bottom. The last hit wins.