Building Vue3 Component Library from Scratch #13 Husky
Tags: vue, husky
Published: 2024-05-30 06:49:34

## 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

```bash
pnpm i husky -D -w
```

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: 

```bash
pnpm pkg set scripts.prepare="husky install"
```

Or you can add script manually.

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

```

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

```bash
npx husky install
```

Then add a commit hook file.


```bash
npx husky add .husky/pre-commit "npm run xxx"
```

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.

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

pnpm run lint:script
pnpm run lint:style
```

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.

```bash
pnpm install --save-dev @commitlint/config-conventional @commitlint/cli -w
```
`@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.

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

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

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

npx --no -- commitlint --edit "$1"
```

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

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/u7oylblpmgznm4ivjd9s.png)

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

```css
feat(global): 添加commitlint规范
```

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

```bash
pnpm add lint-staged -D -w
```

Then, configure it in the package.json file.

```json
{
  "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"
  },
}
```

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

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

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

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