|
| 1 | +# **sr-commit-analyzer** |
| 2 | + |
| 3 | +Customizable commit-analyzer plugin for [semantic-release](https://github.com/semantic-release/semantic-release) based on [conventional-changelog](https://github.com/conventional-changelog/conventional-changelog) |
| 4 | + |
| 5 | +[](https://www.npmjs.com/package/sr-commit-analyzer) |
| 6 | +[](https://www.npmjs.com/package/sr-commit-analyzer) |
| 7 | +[](https://greenkeeper.io/) |
| 8 | +[](https://github.com/vanduynslagerp/sr-commit-analyzer/blob/master/LICENSE) |
| 9 | +[](https://github.com/semantic-release/semantic-release) |
| 10 | +[](http://commitizen.github.io/cz-cli/) |
| 11 | + |
| 12 | +[](https://travis-ci.org/vanduynslagerp/sr-commit-analyzer) |
| 13 | +[](https://codeclimate.com/github/vanduynslagerp/karma-postcss-preprocessor) |
| 14 | +[](https://codecov.io/gh/vanduynslagerp/sr-commit-analyzer) |
| 15 | + |
| 16 | +## Install |
| 17 | +```bash |
| 18 | +npm install --save-dev semantic-release sr-commit-analyzer |
| 19 | +``` |
| 20 | + |
| 21 | +Set the `analyzeCommits` plugin for `semantic-release` in `package.json`. See [semantic-release plugins](https://github.com/semantic-release/semantic-release#plugins). |
| 22 | +```json |
| 23 | +{ |
| 24 | + "release": { |
| 25 | + "analyzeCommits": "sr-commit-analyzer" |
| 26 | + } |
| 27 | +} |
| 28 | +``` |
| 29 | + |
| 30 | +## Options |
| 31 | + |
| 32 | +By default `sr-commit-analyzer` uses the `angular` format described in [Angular convention](https://github.com/conventional-changelog/conventional-changelog/blob/master/packages/conventional-changelog-angular/convention.md). |
| 33 | + |
| 34 | +Additionnal options can be set within the plugin definition in `package.json` to use a different commit format and to customize it: |
| 35 | + |
| 36 | +```json |
| 37 | +{ |
| 38 | + "release": { |
| 39 | + "analyzeCommits": { |
| 40 | + "path": "sr-commit-analyzer", |
| 41 | + "preset": "angular", |
| 42 | + "commitTypes": [ |
| 43 | + {"type": "docs", "scope":"README", "release": "patch"}, |
| 44 | + {"type": "refactor", "release": "patch"}, |
| 45 | + {"type": "style", "release": "patch"} |
| 46 | + ], |
| 47 | + "parserOpts": { |
| 48 | + "noteKeywords": ["BREAKING CHANGE", "BREAKING CHANGES", "BREAKING"] |
| 49 | + } |
| 50 | + } |
| 51 | + } |
| 52 | +} |
| 53 | +``` |
| 54 | + |
| 55 | +| Option | Description | Default | |
| 56 | +| ------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------- | |
| 57 | +| `preset` | [conventional-changelog](https://github.com/conventional-changelog/conventional-changelog) preset (possible values: `angular`, `atom`, `codemirror`, `ember`, `eslint`, `express`, `jquery`, `jscs`, `jshint`). | `angular` | |
| 58 | +| `config` | NPM package name of a custom [conventional-changelog](https://github.com/conventional-changelog/conventional-changelog) preset. | - | |
| 59 | +| `commitTypes` | An external module, a path to a module or an `Array` of rules. See [Commit types](#commit-types). | See [Commit types](#commit-types) | |
| 60 | +| `parserOpts` | Additional [conventional-commits-parser](https://github.com/conventional-changelog/conventional-changelog/tree/master/packages/conventional-commits-parser#conventionalcommitsparseroptions) options that will extends ones loaded by `preset` or `config`. See [Parser options](#parser-options). | - | |
| 61 | + |
| 62 | +**NOTE:** `config` will be overwritten by the values of `preset`. You should use either `preset` or `config`, but not both. Individual properties of `parserOpts` will overwrite ones loaded with `preset` or `config`. |
| 63 | + |
| 64 | +### Commit Types |
| 65 | + |
| 66 | +#### Rules definition |
| 67 | +This is an `Array` of rule objects. A rule object has a `release` property and 1 or more criteria. |
| 68 | +```json |
| 69 | +{ |
| 70 | + "release": { |
| 71 | + "analyzeCommits": { |
| 72 | + "preset": "angular", |
| 73 | + "commitTypes": [ |
| 74 | + {"type": "docs", "scope": "README", "release": "patch"}, |
| 75 | + {"type": "refactor", "scope": "/core-.*/", "release": "minor"}, |
| 76 | + {"type": "refactor", "release": "patch"} |
| 77 | + ] |
| 78 | + } |
| 79 | + } |
| 80 | +} |
| 81 | +``` |
| 82 | +#### Rules matching |
| 83 | + |
| 84 | +Each commit will be compared with each rule and when it matches, the commit will be associated with the release type in the rule's `release` property. If a commit match multiple rules, the highest release type (`major` > `minor` > `patch`) is associated with the commit. |
| 85 | + |
| 86 | +See [release types](lib/default/release-types.js) for the release types hierarchy. |
| 87 | + |
| 88 | +With the previous example: |
| 89 | +* Commits with `type` 'docs' and `scope` 'README' will be associated with a `patch` release. |
| 90 | +* Commits with `type` 'refactor' and `scope` starting with 'core-' (i.e. 'core-ui', 'core-rules', ...) will be associated with a `minor` release. |
| 91 | +* Other commits with `type` 'refactor' (without `scope` or with a `scope` not matching the regexp `/core-.*/`) will be associated with a `patch` release. |
| 92 | + |
| 93 | +#### Default rules matching |
| 94 | + |
| 95 | +If a commit doesn't match any rule in `commitTypes` it will be evaluated agaisnt the [default commit types](lib/default/commit-types.js). |
| 96 | + |
| 97 | +With the previous example: |
| 98 | +* Commits with a breaking change will be associated with a `minor` release. |
| 99 | +* Commits with `type` 'feat' will be associated with a `minor` release. |
| 100 | +* Commits with `type` 'fix' will be associated with a `patch` release. |
| 101 | +* Commits with `type` 'perf' will be associated with a `patch` release. |
| 102 | + |
| 103 | +#### No rules matching |
| 104 | + |
| 105 | +If a commit doesn't match any rules in `commitTypes` or in [default commit types](lib/default/commit-types.js) then no release type will be associated with the commit. |
| 106 | + |
| 107 | +With the previous example: |
| 108 | +* Commits with `type` 'style' will not be associated with a release type. |
| 109 | +* Commits with `type` 'test' will not be associated with a release type. |
| 110 | +* Commits with `type` 'chore' will not be associated with a release type. |
| 111 | + |
| 112 | +#### Multiple commits |
| 113 | + |
| 114 | +If there is multiple commits that match one or more rules, the one with the highest realease type will determine the global release type. |
| 115 | + |
| 116 | +Considering the following commits: |
| 117 | +* `docs(README): Add more details to the API docs` |
| 118 | +* `feat(API): Add a new method to the public API` |
| 119 | + |
| 120 | +With the previous example the release type determine by the plugin will be `minor`. |
| 121 | + |
| 122 | +#### Specific commit properties |
| 123 | + |
| 124 | +The properties to set in the rules will depends on the commit style choosen. For example [conventional-changelog-angular](https://github.com/conventional-changelog/conventional-changelog/blob/master/packages/conventional-changelog-angular/index.js#L9-L13) use the commit properties `type`, `scope` and `subject` but [conventional-changelog-eslint](https://github.com/conventional-changelog/conventional-changelog/blob/master/packages/conventional-changelog-eslint/index.js#L9-L12) uses `tag` and `message`. |
| 125 | + |
| 126 | +For example with `eslint` preset: |
| 127 | +```json |
| 128 | +{ |
| 129 | + "release": { |
| 130 | + "analyzeCommits": { |
| 131 | + "preset": "eslint", |
| 132 | + "commitTypes": [ |
| 133 | + {"tag": "Docs", "message":"/README/", "release": "patch"}, |
| 134 | + {"type": "New", "release": "patch"} |
| 135 | + ] |
| 136 | + } |
| 137 | + } |
| 138 | +} |
| 139 | +``` |
| 140 | +With this configuration: |
| 141 | +* Commits with `tag` 'Docs', that contains 'README' in their header message will be associated with a `patch` release. |
| 142 | +* Commits with `tag` 'New' will be associated with a `patch` release. |
| 143 | +* Commits with `tag` 'Breaking' will be associated with a `major` release (per [default commit types](lib/default/commit-types.js)). |
| 144 | +* Commits with `tag` 'Fix' will be associated with a `patch` release (per [default commit types](lib/default/commit-types.js)). |
| 145 | +* Commits with `tag` 'Update' will be associated with a `minor` release (per [default commit types](lib/default/commit-types.js)). |
| 146 | +* Commits with `tag` 'New' will be associated with a `minor` release (per [default commit types](lib/default/commit-types.js)). |
| 147 | +* All other commits will not be associated with a release type. |
| 148 | + |
| 149 | +#### External package / file |
| 150 | + |
| 151 | +`commitTypes` can also reference a module, either by it's `npm` name or path: |
| 152 | +```json |
| 153 | +{ |
| 154 | + "release": { |
| 155 | + "analyzeCommits": { |
| 156 | + "path": "sr-commit-analyzer", |
| 157 | + "preset": "angular", |
| 158 | + "commitTypes": "config/commit-types.js" |
| 159 | + } |
| 160 | + } |
| 161 | +} |
| 162 | +``` |
| 163 | +```js |
| 164 | +// File: config/commit-types.js |
| 165 | +module.exports = [ |
| 166 | + {type: 'docs', scope: 'README', release: 'patch'}, |
| 167 | + {type: 'refactor', scope: /core-.*/, release: 'minor'}, |
| 168 | + {type: 'refactor', release: 'patch'}, |
| 169 | +]; |
| 170 | +``` |
| 171 | + |
| 172 | +### Parser Options |
| 173 | + |
| 174 | +Allow to overwrite specific [conventional-commits-parser](https://github.com/conventional-changelog/conventional-changelog/tree/master/packages/conventional-commits-parser#conventionalcommitsparseroptions) options. This is convenient to use a [conventional-changelog](https://github.com/conventional-changelog/conventional-changelog) with some customizations without having to create a new module. |
| 175 | + |
| 176 | +The following example uses [Angular convention](https://github.com/conventional-changelog/conventional-changelog/blob/master/packages/conventional-changelog-angular/convention.md) but will consider a commit to be a breaking change if it's body contains `BREAKING CHANGE`, `BREAKING CHANGES` or `BREAKING`. By default the [preset](https://github.com/conventional-changelog/conventional-changelog/blob/master/packages/conventional-changelog-angular/index.js#L14) checks only for `BREAKING CHANGE` and `BREAKING CHANGES`. |
| 177 | +```json |
| 178 | +{ |
| 179 | + "release": { |
| 180 | + "analyzeCommits": { |
| 181 | + "preset": "angular", |
| 182 | + "parserOpts": { |
| 183 | + "noteKeywords": ["BREAKING CHANGE", "BREAKING CHANGES", "BREAKING"], |
| 184 | + } |
| 185 | + } |
| 186 | + } |
| 187 | +} |
| 188 | +``` |
0 commit comments