@gkide/standard-release

standard-release

Commits Message Checking Rules

It is recommended to follow Conventional Commits to make the commits message human and machine readable! More details about the default rules used by standard-release can be found here

Commit Message Format

type(optional-scope): description

optional-body

optional-footer

The default type

type	Changelog Group	Skip Checking	Description
major	Incompatible	false	Bump MAJOR, incompatible
break	Incompatible	false	Bump MAJOR, incompatible
breaking	Incompatible	false	Bump MAJOR, incompatible
security	Security	false	Bump MAJOR, incompatible
deprecated	Deprecated	false	Bump MAJOR, incompatible
minor	Features	false	Bump MINOR, backwards-compatible
feat	Features	false	Bump MINOR, backwards-compatible
feature	Features	false	Bump MINOR, backwards-compatible
patch	Fixed	false	Bump PATCH, bug fixes
fix	Fixed	false	Bump PATCH, bug fixes
bugfix	Fixed	false	Bump PATCH, bug fixes
perf	Changed	false	Improves performance
revert	Changed	false	Reverts commit
refactor	Changed	false	no bugfix or new feature
wip	Preview	false	Work In Process(WIP) or Perview
todo	Preview	false	Work In Process(WIP) or Perview
preview	Preview	false	Work In Process(WIP) or Perview
build	Dependencies	false	Update build system
deps	Dependencies	false	Update dependencies
ci	NONE	false	Update CI configuration
docs	NONE	false	Update documentation
test	NONE	false	Update tests
style	NONE	false	Coding style
chore	NONE	false	Other changes
srsc	NONE	true	NOT checking commit message
skip	NONE	true	NOT checking commit message
init	NONE	true	NOT checking commit message

optional-scope, description and optional-body

• optional-scope is one word, no space of any thing, short is good
• description can be any thing, no long then 80 chars by default
• optional-body can be any thing

optional-footer

• Examples for footer without trace number

[CLOSE] fix something ...

[KNOWN ISSUE] some know issues ...

[BREAKING CHANGES] this commit do breaking changes ...

• Examples for footer with trace number

[CLOSE#123] fix something ...

[KNOWN ISSUE#58] some know issues ...

[BREAKING CHANGES#ab15a9b] this commit do breaking changes ...

Changelog Updating

An example of generated changelog is CHANGELOG.md

Customization

standard-release -i will generated .standard-release directory, which contains customized rules for message checking and changelog generating.

Generated CHANGELOG.md at the repo root directory with default logs The spec.*.js are example files, modify & rename to *.js make it enable.

• spec.changelog.js contains rules for changelog updating
• spec.commit.js contains rules for commit message style checking
• spec.semver.js the same as -X, -Y, -Z, -P and -B, but cmd-line args have high priority

Developer who want to contribution

• package.json specification for newer to JS
• $ npm link . for local dev & preview
• $ npm test or $ npm run test run all tests
• $ npm run xxx run xxx test, see package.json scripts filed for details

Recommendation

It is recommendate to use standard-release together with githooks