Photo by Jon Tyson on Unsplash

Why Should you use Commitizen + Husky for conventional commit and have organised lint

One of the last thing I did on weekend was Git hooks stunt. My Goal was to allow other developers in the organisation to have proper organised lint and commit messages , which should help the developers to know git history in more precise way ,allowing team mate to have faction commit types

Throughout the week i researched the following

• What can be done, to ensure good declarative commit message as good practice
• How to get Commit to define whether it was bug fix , feature added , Major changes or Minor Patch
• What to do , when developers use different lint style in there IDE

Comes to limelight git hooks , which allows developers to use various scripts which controls git to execute :before and :after events such as commit, push and receive. I will go in detail about hooks in some article , point is these hooks paved a solution for my scenarios

So , First thing to do is to install Commitizen Cli tools

npm install commitizen -D -g 

Next , install its adapter npm module which will intialize your project to use the conventional commit message

commitizen init cz-conventional-changelog --save-dev --save-exact

Or if you are using yarn

commitizen init cz-conventional-changelog --yarn --dev --exact 

Next install husky and commitlint cli , configconventional lint-staged and prettier

npm install -D husky @commitlint/{config-conventional, cli} prettier lint-staged

These commands does few things for you

• cz-convention-changelog adapter
• husky and commitlint (checks for lint in your commit message)
• prettier and lint-staged(which runs lint against staged git files)
• commitizen
• Save it these package to devDependency of your package.json
• Adds config.commitizen key to the root of your package.json

//Your Package.json
...
"devDependencies": {
    ...
    "@commitlint/cli": "^9.1.2",
    "@commitlint/config-conventional": "^9.1.2",
    "commitizen": "^4.1.2",
    "cz-conventional-changelog": "^3.2.0",
    "husky": "^4.2.5",
    "lint-staged": "^10.2.11",
    "prettier": "^2.0.5",
},
“config”: {
    “commitizen”: {
        “path”: “./node_modules/cz-conventional-changelog”
      }
   }

Time to Configure commitlint to use conventional config

$ echo "module.exports = {extends: ['@commitlint/config-conventional']}" > commitlint.config.js

this will create a config file named commitlint.config.js to your root directory to setup what convention you want to use

Now time for some Husky action , but why you need Husky

You need to set up the git hooks i.e(which is already talked about ) inside your project to can ensure other members uses that convention. So Husky comes for rescue
It gives us a configuration to setup into package.json.

Setup configuration for Husky in your .huskyrc.json at root project directory

{ 
  "husky": {
    "hooks": {
      "pre-commit": "lint-staged",
      "commit-msg": "commitlint -E HUSKY_GIT_PARAMS",
      "prepare-commit-msg": "exec < /dev/tty && git cz --hook || true"
    }
  }
}

Setup Configuration for lint-staged in .lintstagedrc.json at root project directory

{
“*.{css,less,scss,html,json,jsx,js}”: [“prettier — write”],
“*.{jsx, js}”: [“eslint — max-warnings 0”]
}

Thats it Folks , Now go to your local repo file

• git add -p (to stage files)
• git commit (to start using interactive commitizen cli tool)

It also lint the staged file according to the lint config like prettier

Check git log ,where you can see the magic of git hooks, husky and commitizen happened

• git push origin HEAD

Break your complex problem into simpler sub problem - DP