Tired of Confusing Commits? Here’s How to Fix Them with Commitlint!🚀

⚡Introduction

Let's be honest, we've all seen some downright tragic commit messages. From the dreaded fixed stuff (fixed what, exactly?) to the ever-mysterious WIP (which stays WIP forever), our commit history can sometimes resemble an ancient scroll of cryptic riddles. But fear not! Enter Commitlint – the superhero we need to stop our commit logs from looking like they were written by a sleep-deprived raccoon.

In this guide, I'll walk you through setting up Commitlint in your project, ensuring that every commit follows a structured format. We'll also integrate it with Husky to prevent bad commits from even happening in the first place.

So, let's dive in and clean up our commit history once and for all!

Why Use Commitlint?

🚀 Better Readability

A structured commit message makes it easier to understand what changed and why without decoding cryptic messages.

🔍 Easy Filtering

When using conventional commit formats, filtering commits via git log or tools like standard-version becomes a breeze.

🤖 Automate Changelog Generation

Tools like semantic-release can automatically generate changelogs, version numbers, and even publish releases based on commit messages.

✅ Enforcing Standards

Having rules in place ensures that everyone in the team follows the same commit conventions, reducing confusion.

🛠️ Step 1: Install Commitlint

Time to get our hands dirty. First, install Commitlint in your project:

npm install --save-dev @commitlint/config-conventional @commitlint/cli

This installs Commitlint along with a conventional config that follows Conventional Commits.

🛠️ Step 2: Configure Commitlint

Next, we need to create a configuration file for Commitlint.

Create a commitlint.config.js file in the root of your project and add the following rules:

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

  rules: {
    "type-enum": [
      2,
      "always",
      [
        "feat", // new feature
        "fix", // bug fix
        "docs", // documentation changes
        "style", // code style changes (e.g., formatting)
        "refactor", // code changes that neither fix a bug nor add a feature
        "perf", // performance improvements
        "test", // adding tests
        "chore", // updates to build tools, documentation, etc.
        "ci", // CI related changes
        "build", // changes related to build system or external dependencies
        "revert", // revert a previous commit
        "hotfix", // urgent fixes
      ],
    ],
    "scope-enum": [
      2,
      "always",
      [
        "deps", // dependencies
        "config", // configuration files
        "ui", // user interface related changes
        "backend", // backend related changes
        "frontend", // frontend related changes
        "docs", // documentation related changes
        "build", // build system changes
        "ci", // continuous integration changes
        "tests", // testing related changes
        "release", // release related changes
      ],
    ],
    "subject-case": [2, "always", "lower-case"],
    "header-max-length": [2, "always", 72],
    "footer-max-line-length": [2, "always", 100],
    "body-max-line-length": [2, "always", 100],
  },
};

With this setup, only properly formatted commits will be accepted. This is the config file that I usually prefer, but feel free to tweak it to match your project's needs because let’s be real, one size rarely fits all! 😉

🛠️ Step 3: Add a Commit Hook with Husky

Now, we need to enforce our commit rules. Because let's be honest, rules are pointless if nobody follows them, right? 😆

Install Husky

npm install --save-dev husky

Initialize Husky

npx husky init

This will create a .husky/ directory in your project.

Add a Commitlint Hook

Run the following command to add a commit message hook:

echo "npx --no -- commitlint --edit $1" > .husky/commit-msg

This ensures that every commit message goes through Commitlint before being committed.

🛠️ Step 4: Test Your Setup

Now that we've set up Commitlint and Husky, it's time to test it!

Try committing something incorrectly:

git commit -m "updated stuff"

Boom! You should see an error message telling you that this commit message does not follow the rules. 🎉

Now try committing correctly:

git commit -m "feat(ui): add dark mode support"

Success! You've now enforced structured commit messages in your project. 🏆

🎉 Conclusion

Congratulations! You've successfully set up Commitlint and Husky in your project. Now your commit messages will always be structured and meaningful. 🎯

No more "oops, forgot to mention this" commits!

To recap, we:

1. Installed Commitlint & Husky
2. Configured Commitlint rules
3. Added a Husky hook to enforce rules
4. Tested the setup
5. Optionally added lint-staged for better code quality

Now go forth and commit responsibly! 🚀 Happy coding! 😃