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.

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

Inside your repository run Conventional Commit Creator.

`bash
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:

`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:

`text
--- 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_).

`json
{
"$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:

`text
--- 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_

`text
--- 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.