DEV Community

Mark
Mark

Posted on

Building Vue3 Component Library from Scratch #13 Husky

Why Husky

Even though we have imported prettier and eslint into our project to check the code format, it is inevitable that some people will still commit code that does not conform to the standards to the repository when multiple people are developing. If we pull such code, we have to slowly modify it, which is a troublesome task. Also, to avoid team members committing all sorts of messages, we can introduce husky to solve such problems from the source. Simply put, husky can check whether our code conforms to our configured standards before we commit the code. Let's take a look at how to use husky.

Usage of Husky

install husky

pnpm i husky -D -w
Enter fullscreen mode Exit fullscreen mode

Set the prepare hook in the scripts section of package.json: husky install. When using pnpm install, husky will be executed automatically, so that when others pull our code and perform pnpm install, husky install will be carried out directly. We can use this command:

pnpm pkg set scripts.prepare="husky install"
Enter fullscreen mode Exit fullscreen mode

Or you can add script manually.

 "scripts": {
    ...
    "prepare": "husky install"
  },

Enter fullscreen mode Exit fullscreen mode

Since we haven't run pnpm install, we need to execute it first.

npx husky install
Enter fullscreen mode Exit fullscreen mode

Then add a commit hook file.

npx husky add .husky/pre-commit "npm run xxx"
Enter fullscreen mode Exit fullscreen mode

Then we will find that the .husky/pre-commit file has appeared in the root directory. We modify the command before commit, so that it will perform lint check before submission.

#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"

pnpm run lint:script
pnpm run lint:style
Enter fullscreen mode Exit fullscreen mode

Modify a sourcecode file that does not meet the eslint standard, if you make a commit, you will find that it will first automatically fix it for you before committing. If it cannot be fixed, it will throw an error.

Commitlint

When we look at open source projects, we will see that their code commit messages have information like 'feat: add xxx', 'fix: fix xxx bug', etc. In fact, these also have a standard. Below are some commonly used git commit standards.

  • build: Changes related to compilation, such as releasing versions, changes to project build or dependencies.
  • chore: Other changes, such as changing the build process or adding dependency libraries, tools, etc.
  • ci: Continuous integration changes.
  • docs: Documentation changes.
  • feat: New features, new functions.
  • fix: Bug fixes.
  • perf: Optimizations, such as improving performance or experience.
  • refactor: Code refactoring
  • revert: Roll back to the previous version.
  • style: Code format changes, note not CSS changes.
  • test: Test case changes.

In order to have our team use these commit standards, we need to use commitlint. Firstly, we need to install a few tools.

pnpm install --save-dev @commitlint/config-conventional @commitlint/cli -w
Enter fullscreen mode Exit fullscreen mode

@commitlint/config-conventional is a standard configuration, which indicates what standard is used to perform message verification. By default, it is Angular's commit standard. @commitlint/cli is a command line tool that uses lint rules to check commit records.

Create commitlint.config.cjs, where you can customize the message standards for git commits.

module.exports = {
  extends: ['@commitlint/config-conventional']
};
Enter fullscreen mode Exit fullscreen mode

Then add 'npx --no -- commitlint --edit "$1"' in the .husky/commit-msg file."

#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

npx --no -- commitlint --edit "$1"
Enter fullscreen mode Exit fullscreen mode

if you submit a message that does not meet to the rules, you will find that an error is reported.

Image description

The correct submission format should be '(<?scope>): ', for example

feat(global): 添加commitlint规范
Enter fullscreen mode Exit fullscreen mode

Add commitlint standards.

Config lint-staged

According to the configuration above, we can achieve the effect we want. However, we will find that every time we submit code, ESlint or Stylelint will check all files. What we need is to only let them check the newly added files. Therefore, we can use lint-staged to solve this problem.

Firstly, install lint-staged

pnpm add lint-staged -D -w
Enter fullscreen mode Exit fullscreen mode

Then, configure it in the package.json file.

{
  "lint-staged": {
    "src/**/*.{js,jsx,ts,tsx,vue}": [
      "eslint --ext .js,.jsx,.vue,.ts,.tsx --fix --quiet ./",
      "stylelint --fix \"packages/components/src/**/*.{css,less}\""
    ]
  },
  "scripts": {
    "lint-staged": "lint-staged"
  },
}
Enter fullscreen mode Exit fullscreen mode

Finally, modify the '.husky/pre-commit' file.

#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"
pnpm run lint-staged
Enter fullscreen mode Exit fullscreen mode

Now it will only check the files we have added to the staging area.

The final source code: https://github.com/markliu2013/StellarNovaUI

Top comments (0)