DEV Community: Tal Ohana

Husky and Commitlint for Clean Git Log

Tal Ohana — Fri, 29 May 2020 10:55:03 +0000

You can find the source code of the article in this github repo

Introduction 🚀

In our programming life most of us came across git logs which looked like this

4a3e5ba fix
c8a54df style change
0677dc5 fix
84ebabf fix
dbf7300 fix bug
6942670 pr changes
32d06bc pr changes

It's impossible to understand from these commits what is going on in our repository and makes it harder to navigate between commits.

There is a simple solution you can apply in 5 minutes using husky and commitlint to avoid this problem, and the sooner the better!

Husky 🐺

Git provides us with something called Git Hooks, simply lets us hook into specific git workflow (commiting, pushing, etc) and run commands.

Although you can write your git hooks from scratch, there is an easier solution using husky.

Heading to your project, add husky by running npm i -D husky.
Now we can test husky by adding some hook to our package.json file

{
  .
  .
  "husky": {
    "hooks": {   
      "pre-commit": "echo git hooks are awesome!"
    }
  }
}

And then when commiting you should see our hook running

husky > pre-commit (node v10.17.0)
git hooks are awesome!
[master ec5599a] first commit with husky
 1 file changed, 3 insertions(+)

Commitlint 📝

Commitlint, as it's name suggests, helps us to lint our git commits.

First, add commitlint cli to our project by running npm i -D @commitlint/cli

Now you can choose from various conventions listed here, for this blogpost i'm going to use angular's convention which follows the commit template of

type(scope?): subject  #scope is optional

Adding it by running npm i -D @commitlint/config-conventional
Lastly, we need to create commitlint config file named commitlint.config.js

// commitlint.config.js
module.exports = {
  extends: ["@commitlint/config-conventional"]
};

Now we can test commitlint, for example if we run commitlint with text that does not follow the conventional commit pattern we will get an error

> echo fix | npx commitlint
⧗    input: fix
✖   subject may not be empty [subject-empty]
✖   type may not be empty [type-empty]

✖   found 2 problems, 0 warnings
ⓘ   Get help: https://github.com/conventional-changelog/commitlint/#what-is-commitlint

Putting it all together 👩🏽‍💻

What we actually want is that for against every git commit we run, commitlint will lint our commit message, and abort if any errors comes along.

For this we only need to add the following husky hook

{
  .
  .
  "husky": {
    "hooks": {
      "commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
    }
  }
}

Now if we try to commit with non-conventional message we should get commitlint's errors and the commit will be aborted

> echo hello >> temp_file
> git commit -am "fix"

husky > commit-msg (node v10.17.0)
⧗   input: fix
✖   subject may not be empty [subject-empty]
✖   type may not be empty [type-empty]

✖   found 2 problems, 0 warnings
ⓘ   Get help: https://github.com/conventional-changelog/commitlint/#what-is-commitlint

husky > commit-msg hook failed (add --no-verify to bypass)

As mentioned in the last line of the output, you can suppress errors by appending --no-verify to our git commands, use with caution ⚠️

Boost Your TypeScript Project with ESLint, Prettier and lint-staged! 🔥🔥🔥

Tal Ohana — Fri, 14 Feb 2020 20:10:22 +0000

The source code of this article can be found in this github repository

Introduction 🔮

There are many tools today that makes you really productive, they take away fixing small errors and formatting your code.

In this tutorial we are going to build a TypeScript project from scratch, add it linting and formatting capabilities and at the end making it automatic with every git commit you run.

Creating a TypeScript Project 🚀

We are going to create the simplest TypeScript project. In Order to do so, run the following commands

mkdir typescript-example
cd $_
npm init -y
npm i -D typescript
npx tsc --init

Adding ESLint 📖

First, let's understand what ESLint is all about, from eslint getting-started

ESLint is a tool for identifying and reporting on patterns found in ECMAScript/JavaScript code, with the goal of making code more consistent and avoiding bugs.

Pretty straight forward, it's something you really want in your project.
To add ESLint we'll need to add the following packages

npm i -D eslint @typescript-eslint/parser @typescript-eslint/eslint-plugin

and add two files to our project folder:
A file named .eslintrc.js which contains all our ESLint configurations

// .eslintrc.js
module.exports = {
  root: true,
  parser: "@typescript-eslint/parser",
  plugins: ["@typescript-eslint"],
  extends: [
    "eslint:recommended",
    "plugin:@typescript-eslint/eslint-recommended",
    "plugin:@typescript-eslint/recommended"
  ]
};

You can explore the recommended rules for eslint:recommended here and for @typescript-eslint/recommended here.

A File named .eslintignore so we won't compile node_modules

// .eslintignore
node_modules

PS, add your compiled code folder here or any other folder you wish to ignore

Final thing, let's add two npm scripts that lint and fix the code for us

"scripts": {
  "lint": "eslint . --ext .js,.jsx,.ts,.tsx",
  "lint:fix": "npm run lint -- --fix"
}

In order to test the scripts, add a dummy index.ts file with the following content

const x: number = 123;

console.log(x);

We can see that the type annotation (number) is redundant and can be omitted, after running npm run tslint:fix the file is linted and fixed for us

const x = 123;

console.log(x);

Adding Prettier 💎

So what is Prettier? from Prettier Docs

Prettier is an opinionated code formatter
It removes all original styling* and ensures that all outputted code conforms to a consistent style.

Long story short, you won't have to argue about tabs vs spaces (or any other code-style) ever again!

To add Prettier and integrate it with ESLint add the following packages:

npm i -D prettier eslint-config-prettier eslint-plugin-prettier

Next, we'll update .eslintrc.js to ignore all formatting rules that are not from Prettier, and then use Prettier as an ESLint rule

// .eslintrc.js
module.exports = {
  root: true,
  parser: "@typescript-eslint/parser",
  plugins: [
    "@typescript-eslint",
    "prettier"
  ],
  rules: {
    "prettier/prettier": "error"
  },
  extends: [
    "eslint:recommended",
    "plugin:prettier/recommended",
    "plugin:@typescript-eslint/eslint-recommended",
    "plugin:@typescript-eslint/recommended"
  ]
};

In order to test this, let's create a simple .prettierrc file that contains our Prettier options

// .prettierrc
{
  "singleQuote": true
}

Back to our index.ts let's add some unformatted code

const x: string = "Unformatted String"

console.log(x);

after running npm run tslint:fix we can see the fixed and formatted file

const x = 'Unformatted String';

console.log(x);

Adding lint-staged and husky 🐶

It's pretty easy to forget linting and formatting our code before comitting and pushing it, lint-staged and husky to the rescue!

Husky is a package that helps us integrate with git hooks and lint-staged is helping us to lint our staged files.

First, let's initialize git by running git init and creating .gitingore file

// .gitignore
node_modules

Let's add them by running

npm i -D husky lint-staged

and add their configuration to our package.json

{
  "husky": {
    "hooks": {
      "pre-commit": "lint-staged"
    }
  },
  "lint-staged": {
    "*.{js,jsx,ts,tsx}": "eslint --cache --fix"
  }
}

That's all! now when we git commit our files we'll get linting and formatting automatically.