feat: 🎸 added commit linting to ci

rjchow · Sep 23, 2019 · 23ce5b1 · 23ce5b1
1 parent ab59c2b
commit 23ce5b1
Show file tree

Hide file tree

Showing 6 changed files with 1,239 additions and 19 deletions.
diff --git a/.circleci/config.yml b/.circleci/config.yml
@@ -8,6 +8,7 @@ jobs:
       - run:
           name: install
           command: npm install
+      - run: npm run commitlint-circle
       - run:
           name: lint
           command: npm run lint

diff --git a/.yo-rc.json b/.yo-rc.json
@@ -0,0 +1,7 @@
+{
+  "generator-semantic-module": {
+    "packager": "npm",
+    "commitizen-adapter": "@commitlint/prompt",
+    "commitlint-config": "@commitlint/config-conventional"
+  }
+}
diff --git a/README.md b/README.md
@@ -59,17 +59,8 @@ DEBUG="PLACEHOLDER_PROJECT_NAME:*" npm run dev
 
 This boiler plate uses the **semantic-release** package to manage versioning. Once it has been set up, version numbers and Github release changelogs will be automatically managed. **semantic-release** uses the commit messages to determine the type of changes in the codebase. Following formalized conventions for commit messages, **semantic-release** automatically determines the next [semantic version](https://semver.org) number, generates a changelog and publishes the release.
 
-By default **semantic-release** uses [Angular Commit Message Conventions](https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#-git-commit-guidelines). The commit message format can be changed with the [`preset` or `config` options](docs/usage/configuration.md#options) of the [@semantic-release/commit-analyzer](https://github.com/semantic-release/commit-analyzer#options) and [@semantic-release/release-notes-generator](https://github.com/semantic-release/release-notes-generator#options) plugins.
 
-Tools such as [commitizen](https://github.com/commitizen/cz-cli), [commitlint](https://github.com/conventional-changelog/commitlint) or [semantic-git-commit-cli](https://github.com/JPeer264/node-semantic-git-commit-cli) can be used to help contributors and enforce valid commit messages.
-
-Here is an example of the release type that will be done based on a commit messages:
-
-| Commit message                                                                                                                                                                                   | Release type                       |
-| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------- |
-| `fix(pencil): stop graphite breaking when too much pressure applied`                                                                                                                             | Patch Release (1.0.x)              |
-| `feat(pencil): add 'graphiteWidth' option`                                                                                                                                                       | ~~Minor~~ Feature Release (1.x.0)  |
-| `perf(pencil): remove graphiteWidth option`<br><br>`BREAKING CHANGE: The graphiteWidth option has been removed.`<br>`The default graphite width of 10mm is always used for performance reasons.` | ~~Major~~ Breaking Release (x.0.0) |
+Use `npm run commit` instead of `git commit` in order to invoke Commitizen commit helper that helps with writing properly formatted commit messages.
 
 ## API
 

diff --git a/commitlint.config.js b/commitlint.config.js
@@ -0,0 +1,8 @@
+/* eslint-env node */
+
+module.exports = {
+  extends: ["@commitlint/config-conventional"],
+
+  // Add your own rules. See http://marionebl.github.io/commitlint
+  rules: {}
+};