Installations

npm install @digitalroute/cz-conventional-changelog-for-jira

Pull Requests

Open

1

Total

50

Closed

10

Merged

39

Issues

Open

14

Total

35

Closed

21

Releases

41

v8.0.1

Published on 05 May 2023

v8.0.0

Published on 20 Dec 2022

v7.5.1

Published on 13 Dec 2022

v7.5.0

Published on 12 Dec 2022

v7.4.2

Published on 18 Oct 2022

v7.4.1

Published on 09 Oct 2022

View all 41 releases

Developer

digitalroute

Developer Guide

BETA

Module System

CommonJS

Min. Node Version

>= 10

Typescript Support

No

Node Version

16.20.0

NPM Version

8.19.3 Statistics

66 Stars

111 Commits

63 Forks

2 Watching

70 Branches

27 Contributors

Updated on 28 Nov 2024

Languages

JavaScript (100%)

Total Downloads

Cumulative downloads

Total Downloads

5,475,299

Last day

-22.1%

9,272

Compared to previous day

Last week

-3.5%

52,863

Compared to previous week

Last month

2.5%

227,634

Compared to previous month

Last year

44%

2,381,848

Compared to previous year

Daily Downloads

Weekly Downloads

Monthly Downloads

Yearly Downloads

Dependencies

10

boxen chalk commitizen cz-conventional-changelog inquirer lodash.map longest right-pad word-wrap @commitlint/load

Dev Dependencies

9

@types/chai @types/mocha chai cosmiconfig mocha mock-require prettier semantic-release semver

Optional Dependencies

1

@commitlint/load

Versions

cz-conventional-changelog-for-jira

Part of the commitizen/cz-cli family. Prompts for conventional changelog standard and also prompts for a mandatory JIRA issue.

Features

Works seamlessly with semantic-release 🚀
Works seamlessly with Jira smart commits
Automatically detects the Jira issue from the branch name

Quickstart

Installation

1npm install commitizen @digitalroute/cz-conventional-changelog-for-jira

and then add the following to package.json:

1{
2  "scripts": {
3    "commit": "git-cz"
4  },
5  "config": {
6    "commitizen": {
7      "path": "./node_modules/@digitalroute/cz-conventional-changelog-for-jira"
8    }
9  }
10}

Usage

Gif of terminal when using cz-conventional-changelog-for-jira

Configuration

Like commitizen, you can specify the configuration of cz-conventional-changelog-for-jira through the package.json's config.commitizen key, or with environment variables.

Environment variable	package.json	Default	Description
CZ_JIRA_MODE	jiraMode	true	If this is set to true, CZ will ask for a Jira issue and put it in the commit head. If set to false CZ will ask for the issue in the end, and can be used for GitHub.
CZ_MAX_HEADER_WIDTH	maxHeaderWidth	72	This limits how long a commit message head can be.
CZ_MIN_HEADER_WIDTH	minHeaderWidth	2	This limits how short a commit message can be.
CZ_MAX_LINE_WIDTH	maxLineWidth	100	Commit message bodies are automatically wrapped. This decides how long the lines will be.
CZ_SKIP_SCOPE	skipScope	true	If scope should be used in commit messages.
CZ_SKIP_TYPE	skipType	false	If type should be used in commit messages.
CZ_SKIP_DESCRIPTION	skipDescription	false	If description should be used in commit messages.
CZ_SKIP_BREAKING	skipBreaking	false	If breaking changes should be used in commit messages.
	scopes	undefined	A list (JS Array) of scopes that will be available for selection. Note that adding this will change the scope field from Inquirer 'input' to 'list'.
CZ_TYPE	defaultType	undefined	The default type.
CZ_SCOPE	defaultScope	undefined	The default scope.
CZ_CUSTOM_SCOPE	customScope	false	Whether user can provide custom scope in addition to predefined ones
CZ_SUBJECT	defaultSubject	undefined	A default subject.
CZ_BODY	defaultBody	undefined	A default body.
CZ_ISSUES	defaultIssues	undefined	A default issue.
CZ_JIRA_OPTIONAL	jiraOptional	false	If this is set to true, you can leave the JIRA field blank.
CZ_JIRA_PREFIX	jiraPrefix	"DAZ"	If this is set it will be displayed as the default JIRA ticket prefix
CZ_JIRA_LOCATION	jiraLocation	"pre-description"	Changes position of JIRA ID. Options: `pre-type`, `pre-description`, `post-description`, `post-body`
CZ_JIRA_PREPEND	jiraPrepend	""	Prepends JIRA ID with an optional decorator. e.g.: `[DAZ-1234`
CZ_JIRA_APPEND	jiraAppend	""	Appends JIRA ID with an optional decorator. e.g.: `DAZ-1234]`
CZ_EXCLAMATION_MARK	exclamationMark	false	On breaking changes, adds an exclamation mark (!) after the scope, e.g.: `type(scope)!: break stuff`. When activated, reduces the effective allowed header length by 1.

Jira Location Options

pre-type:

1JIRA-1234 type(scope): commit subject

pre-description:

1type(scope): JIRA-1234 commit subject

post-description:

1type(scope): commit subject JIRA-1234

post-body:

1type(scope): commit subject
2
3JIRA-1234

1type(scope): commit subject
2
3this is a commit body
4
5JIRA-1234

Dynamic Configuration

Alternatively, if you want to create your own profile, you can use the configurable approach. Here is an example: ./index.js

1const custom = require('@digitalroute/cz-conventional-changelog-for-jira/configurable');
2// You can do this optionally if you want to extend the commit types
3const defaultTypes = require('@digitalroute/cz-conventional-changelog-for-jira/types');
4
5module.exports = custom({
6  types: {
7    ...defaultTypes,
8    perf: {
9      description: 'Improvements that will make your code perform better',
10      title: 'Performance'
11    }
12  },
13  skipScope: false,
14  scopes: ['myScope1', 'myScope2'],
15  customScope: true
16});

./package.json

1{
2  "config": {
3    "commitizen": {
4      "path": "./index.js"
5    }
6  }
7}

This example would:

Display "perf" as an extra commit type
Ask you to add a commit scope
Limit the scope selection to either myScope or myScope2

List of all supported configurable options when using the configurable approach:

Key	Default	Description
jiraMode	true	If this is set to true, CZ will ask for a Jira issue and put it in the commit head. If set to false CZ will ask for the issue in the end, and can be used for GitHub.
maxHeaderWidth	72	This limits how long a commit message head can be.
minHeaderWidth	2	This limits how short a commit message can be.
maxLineWidth	100	Commit message bodies are automatically wrapped. This decides how long the lines will be.
skipScope	true	If scope should be used in commit messages.
defaultType	undefined	The default type.
defaultScope	undefined	The default scope.
defaultSubject	undefined	A default subject.
defaultBody	undefined	A default body.
defaultIssues	undefined	A default issue.
jiraPrefix	'DAZ'	The default JIRA ticket prefix that will be displayed.
types	./types.js	A list (JS Object) of supported commit types.
scopes	undefined	A list (JS Array) of scopes that will be available for selection. Note that adding this will change the scope field from Inquirer 'input' to 'list'.
customScope	false	If this is set to true, users are given an option to provide custom scope aside the ones predefined in 'scopes' array. In this case a new option named 'custom' appears in the list and once chosen a prompt appears to provide custom scope
jiraOptional	false	If this is set to true, you can leave the JIRA field blank.
jiraLocation	"pre-description"	Changes position of JIRA ID. Options: `pre-type`, `pre-description`, `post-description`, `post-body`
jiraPrepend	""	Prepends JIRA ID with an optional decorator. e.g.: `[DAZ-1234`
jiraAppend	""	Appends JIRA ID with an optional decorator. e.g.: `DAZ-1234]`
exclamationMark	false	On breaking changes, adds an exclamation mark (!) after the scope, e.g.: `type(scope)!: break stuff`. When activated, reduces the effective allowed header length by 1.

Commitlint

If using the commitlint js library, the "maxHeaderWidth" configuration property will default to the configuration of the "header-max-length" rule instead of the hard coded value of 72. This can be ovewritten by setting the 'maxHeaderWidth' configuration in package.json or the CZ_MAX_HEADER_WIDTH environment variable.

No vulnerabilities found.

10

Dangerous-Workflow

Determines if the project's GitHub Action workflows avoid dangerous patterns.

10

Binary-Artifacts

Determines if the project has generated executable (binary) artifacts in the source repository.

10

License

Determines if the project has defined a license.

8

Code-Review

Determines if the project requires human code review before pull requests (aka merge requests) are merged.

3

Pinned-Dependencies

Determines if the project has declared and pinned the dependencies of its build process.

0

Maintained

Determines if the project is "actively maintained".

0

Token-Permissions

Determines if the project's workflows follow the principle of least privilege.

0

CII-Best-Practices

Determines if the project has an OpenSSF (formerly CII) Best Practices Badge.

0

Security-Policy

Determines if the project has published a security policy.

0

Fuzzing

Determines if the project uses fuzzing.

0

SAST

Determines if the project uses static code analysis.

0

Vulnerabilities

Determines if the project has open, known unfixed vulnerabilities.

Score

3.8

/10

Last Scanned on 2024-11-25

The Open Source Security Foundation is a cross-industry collaboration to improve the security of open source software (OSS). The Scorecard provides security health metrics for open source projects.

Learn More