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
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"
Or you can add script manually.
"scripts": {
...
"prepare": "husky install"
},
Since we haven't run pnpm install, we need to execute it first.
npx husky install
Then add a commit hook file.
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.
#!/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.
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.
module.exports = {
extends: ['@commitlint/config-conventional']
};
Then add 'npx --no -- commitlint --edit "$1"' in the .husky/commit-msg file."
#!/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.
The correct submission format should be '(<?scope>): ', for example
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
pnpm add lint-staged -D -w
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"
},
}
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
Top comments (0)