背景:由于每个人的代码风格不一致,在大型项目或者其他多人合作的项目中,如果无法统一代码风格,非常不利于代码的维护,甚至可能出现一些不必要的错误。因此,代码风格趋于一致很重要。在这个过程中会存在许多小细节,所以需要工具帮助我们检测代码中可能出现的错误,同时尽可能将代码风格趋于一致,前端常用的工具是eslint,prettier以及stylelint。
你以为我要说的是这三个工具么,😈,嘿嘿嘿,我就不说(其实是内容过多还没整理完,保证一定会补),本章内容的前提是在eslint,prettier以及stylelint已经安装并且在项目中发挥着作用。
点击跳转husky文档地址
当校验出一些不合规范的代码时,任务其实只完成了一半,接下来当然是改代码,将代码修改成符合规范的样子。但是,lint工具做的主要工作是校验,在实际操作中会发现,即使没有修改代码,仍然可以毫无阻碍的提交代码,代码校验很容易就会变成一个形式化的事情,比较好的一个方法就是在代码提交之前添加一个拦路🐶,如果发现存在不规范的代码,就阻止代码的提交工作。这就是husky做的事情。
You can use it to lint your commit messages, run tests, lint code, etc… when you commit or push. Husky supports all Git hooks.
理解了husky是什么之后,接下来就是怎么在项目中配置已经使用husky,因为一直使用的都是npm,所以在此以npm的安装方式为主进行说明,yarn方式的配置可以参考文档。
npm install husky -D
npx husky install
npm pkg set scripts.prepare="husky install"
package.json
中添加script,等同于自己手动添加如下代码:{
"scripts": {
"prepare": "husky install",
}
}
npx husky add .husky/pre-commit "npm run lint" git add .husky/pre-commit
test: "eslint pages/"
,那标题这段代码的前半段就应该改为npx husky add .husky/pre-commit "npm run test"
{
"scripts": {
"prepare": "husky install",
"lint":"eslint src/"
}
}
执行代码之后,代码中将添加一个.husky文件夹,以及pre-commit文件,文件内容如下:
#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"
npm run lint
点击跳转lint-staged
接入husky之后大部分代码自动校验以及代码拦截都已经完成了,一般小型项目已经足够使用。但对于大型项目而言,新的问题又出现了,如果项目中代码特别特别的多,但本次修改只是改了其中一两个文件,提交代码的时候会怎么样呢?很显然,husky会将全部代码都检查一遍,理论上而言,以前的代码默认都是校验完成的(除非是在项目中间加的husky,或者有人提交的时候跳过了校验),所以本质上只需要校验本次修改之后的代码是否符合lint规则就好,这个,就是lint-staged的作用所在。
Run linters against staged git files and don’t let 💩 slip into your code base!
安装lint-staged之后,每次提交时只会检查本次提交的文件
接下来就是如何安装使用,同样的,这里的安装步骤以npm为主,yarn请参考别的文档哈
npm install lint-staged -D
npm pkg set
,但我才疏学浅怎么都没研究明白,有知道怎么写命令的大神要是路过可以🦶一jio,十分感谢😄😄👀👀{
"scripts": {
"precommit": "lint-staged"
"lint":"eslint src/"
},
"lint-staged": {
"*.js": [
"eslint --fix"
]
// "*.js": "项目中所有的 js 文件",
// "**/*.js": "项目中所有的 js 文件",
// "src/*.js": "src目录中所有的 js 文件",
// "src/**/*.js": "src文件夹中所有的 js 文件"
}
}
#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"
npm run precommit
如果还有什么好用的工具,期待一起研究,一起交流