Boost your productivity by simplifying your development workflow with efficient tools! Learn how standard-version, Husky, commitlint, and lint-staged can transform your coding experience by automating processes and ensuring high-quality commits. 🎉🚀

In the dynamic world of software development, it is crucial to adopt tools that optimize and simplify the workflow. Whether you’re a seasoned developer or just starting out in your career, finding ways to make the development process smoother can significantly improve your productivity and the quality of your code. In this article, we’ll explore how standard-version, Husky, commitlint, and lint-staged can help you automate repetitive tasks, ensure consistent commit messages, and maintain clean code. Let’s dive into this world of good practices and efficiency!

CommitLint

CommitLint is a handy tool that guides you to write consistent and well-structured commit messages. It gently reminds you of good writing practices, ensuring that each message is clear and easy to understand, even for other members of your team. Basically, it’s like having an assistant who makes sure your commit messages are always on top!

Installation First, install CommitLint and its conventional config:

pnpm add -D @commitlint/{cli,config-conventional}

Configuration

Create a .commitlint.config.js file

const typeEnum = [
  "feat", 
  "fix", 
  "style",
  "refactor",
  "test", 
  "chore",
  "docs",
  "perf",
];

module.exports = {
  extends: ["@commitlint/config-conventional"],
  rules: {
    "subject-case": [2, "always", "sentence-case"],
    "subject-empty": [2, "never"],
    "type-empty": [2, "never"],
    "type-enum": [2, "always", typeEnum],
  },
  plugins: [
    {
      rules: {
        "type-enum": ({ type, subject }) => {
          if (typeEnum?.includes(type) && /^\(JIRA-\d+\) /.test(subject)) {
            return [true];
          }
          return [
            false,
            !/^\(JIRA-\d+\) /.test(subject)
              ? `Commit message should start with <type>: '(JIRA-<number>) '.`
              : !typeEnum?.includes(type) &&
                `Type should be 'feat',
       'fix',
       'style',
       'refactor',
       'test',`,
          ];
        },
      },
    },
  ],
};

Context

The file shown is a commitlint configuration file. Its purpose is to ensure that each commit message follows a specific format. Commits can be categorized by type, and they must include a JIRA ticket identifier in the message. The goal is to standardize commit messages to make version control and reading history easier.

const typeEnum = [
  "feat", 
  "fix", 
  "style",
  "refactor",
  "test", 
  "chore",
  "docs",
  "perf",
];

Explanation

This typeEnum array defines the allowed commit types:

• feat: Adding a new feature. • fix: Fixing a bug. • style: Changes related to formatting (e.g., indentation, whitespace) that don’t affect the code’s logic. • refactor: Code changes that neither add a feature nor fix a bug. • test: Adding or modifying tests. • chore: Changes that don’t modify the codebase (e.g., configuration changes, maintenance). • docs: Updates to documentation. • perf: Performance improvements.

Commitlint Configuration

module.exports = {
  extends: ["@commitlint/config-conventional"],
  rules: {
    "subject-case": [2, "always", "sentence-case"],
    "subject-empty": [2, "never"],
    "type-empty": [2, "never"],
    "type-enum": [2, "always", typeEnum],
  },
  plugins: [
    {
      rules: {
        "type-enum": ({ type, subject }) => {
          if (typeEnum?.includes(type) && /^\(JIRA-\d+\) /.test(subject)) {
            return [true];
          }
          return [
            false,
            !/^\(JIRA-\d+\) /.test(subject)
              ? `Commit message should start with <type>: '(JIRA-<number>) '.`
              : !typeEnum?.includes(type) &&
                `Type should be one of 'feat', 'fix', 'style', 'refactor', 'test',`,
          ];
        },
      },
    },
  ],
};

In this example, I’m using JIRA for ticket management, but you can easily adjust the format to work with GitHub or any other project tracking tool.

Explanation

• extends: This line extends a predefined configuration, @commitlint/config-conventional, which follows standard commit conventions. • rules: • “subject-case”: [2, “always”, “sentence-case”]: The subject (commit message description) must always be written in lowercase, following the sentence-case format. • “subject-empty”: [2, “never”]: The subject of the commit must not be empty. • “type-empty”: [2, “never”]: The commit type (e.g., “feat”, “fix”) must not be empty. • “type-enum”: [2, “always”, typeEnum]: The commit type must be one of the defined typeEnum values (e.g., “feat”, “fix”).

Plugins

The plugin added here customizes the type-enum rule to add an extra requirement involving JIRA identifiers.

• type-enum: This custom rule ensures that:

1. The commit type is included in the typeEnum.
2. The commit subject starts with a JIRA identifier in the form (JIRA-<number>). If these conditions are not met, a specific error message is returned to guide the developer: • If the JIRA identifier is missing, it asks that the commit message start with (JIRA-<number>). • If the commit type is invalid, it indicates which types are allowed.

This commitlint configuration file is designed to enforce consistent commit messages by requiring a specific commit type and a JIRA identifier. This improves project tracking and traceability by linking commits to development tickets.

This type of setup is particularly useful in projects following Agile methodologies or those using a ticketing system like JIRA to link commits with development tasks.

Husky

Husky is used to manage Git hooks, automating tasks before commits and pushes.

Installation

Add Husky to your project and set it up:

pnpm add — save-dev husky
pnpm exec husky install

Configuration Add Git hooks:

npx husky add .husky/pre-commit "pnpm test"
npx husky add .husky/commit-msg "pnpm dlx commitlint — edit $1

This configuration ensures that tests are run before every commit and commit messages are validated against the CommitLint rules.

LintStaged

LintStaged runs linters on staged files, ensuring only committed files are linted.

Installation Install LintStaged:

pnpm add -D lint-staged

Configuration Create a .lintstagedrc.json file to define linting rules:

{
 "src/**/*.{js,jsx,ts,tsx}": [
 "prettier — write",
 "eslint — fix",
 "eslint"
 ],
 "src/**/*.{json,css,md}": [
 "prettier — write"
 ]
}

This configuration formats JavaScript/TypeScript files with Prettier, fixes linting issues with ESLint, and ensures that JSON, CSS and Markdown files are also formatted.

Standard Version

Standard Version automates the versioning and changelog generation based on conventional commits.

Installation Add Standard Version to your project:

pnpm add -D standard-version

Configuration Create a .versionrc.json file:

{
  "types": [
    {
      "type": "feat",
      "section": "✨ Features"
    },
    {
      "type": "fix",
      "section": "🐛 Bug Fixes"
    },
    {
      "type": "chore",
      "hidden": false,
      "section": "🚚 Chores"
    },
    {
      "type": "docs",
      "hidden": false,
      "section": "📝 Documentation"
    },
    {
      "type": "style",
      "hidden": false,
      "section": "💄 Styling"
    },
    {
      "type": "refactor",
      "hidden": false,
      "section": "♻️ Code Refactoring"
    },
    {
      "type": "perf",
      "hidden": false,
      "section": "⚡️ Performance Improvements"
    },
    {
      "type": "test",
      "hidden": false,
      "section": "✅ Testing"
    }
  ]
}

Add release scripts to package.json:

"scripts": {
 "release": "standard-version",
 "release:minor": "standard-version — release-as minor",
 "release:patch": "standard-version — release-as patch",
 "release:major": "standard-version — release-as major"
}

Putting It All Together

With these tools configured, your development workflow will benefit from:

1. Consistent Commit Messages: Ensured by CommitLint and Husky.
2. Automated Linting: Managed by LintStaged to only affect staged files.
3. Streamlined Versioning: Handled by Standard Version, automating version bumps and changelog generation.

Example Workflow

1.Before Commit: Husky runs pre-commit hooks to lint and test your code. 2. Commit Message: CommitLint checks your commit message against defined rules. 3. Release Process: Use Standard Version scripts to automate versioning and changelog updates.

Conclusion

By integrating CommitLint, Husky, LintStaged, and Standard Version into your development workflow, you can maintain consistency in commit messages, automate code quality checks, and streamline versioning processes. This not only enhances code quality but also improves collaboration within your team.

Feel free to share your experiences or ask questions in the comments below!