上一篇文章介绍了如何一键格式化 wxss
文件。
明天介绍利用 Git Hooks 钩子实现提交代码主动执行此前的 ESLint、Prettier 命令,以保障咱们提交的代码是不丑的。
一、Git 钩子
Git 提供了一些钩子,能在特定的重要操作产生时触发自定义脚本。
当咱们执行 git init
初始化一个 Git 版本库时,Git 会默认在 .git/hooks
目录中搁置一些示例脚本(Shell 脚本)。这些示例脚本都是以 .sample
结尾,如果你想启用它们,得先移除这个后缀。
把一个正确命名(不带扩展名)且可执行的文件放入 .git/hooks
目录下,即可激活该钩子脚本。这样一来,它就能被 Git 调用。
二、罕用钩子
- pre-commit
该钩子在键入提交信息前运行。它用于查看行将提交的快照,例如,查看是否有所脱漏,确保测试运行,以及核查代码。如果该钩子以非零值退出,Git 将放弃此次提交,不过你能够用 git commit --no-verify
来绕过这个环节。你能够利用该钩子,来查看代码格调是否统一、尾随空白字符是否存在,或新办法的文档是否适当等等。
三、husky
husky 是一个为 Git 客户端减少 hook
的工具。当其装置到所在仓库时,它会主动在 .git/hooks
减少相应的钩子实现在 pre-commit
阶段就执行一系列保障每一个 commit
的正确性。
当然,pre-commit
阶段执行的命令,当然要保障其速度不要太慢,每次 commit
都等很久也不是好的体验。
1. 装置 npm-run-all
它用于同步或者并行执行 npm script 脚本。
$ yarn add --dev npm-run-all@4.1.5
于是乎,联合之前的 npm script,再通过 npm-run-all 来把几个命令串起来。
{
"scripts": {"format:all": "npm-run-all -p prettier:wxss:acss prettier:fix -s eslint:fix"}
}
这行命令做了什么:首先并行执行 prettier:wxss:acss
和 prettier:fix
两个命令,等到执行完之后才会执行 eslint:fix
命令。
npm-run-all -p
示意并行操作。npm-run-all -s
示意按程序操作。- 它同时提供了下面两条命令的简写版 API,别离对应
run-p
、run-s
。
因为 prettier:wxss:acss
和 prettier:fix
匹配的文件没有重合的,所以能够并行操作。至于为什么先进行 Prettier 格式化,再进行 ESLint 查看,因为它们两个是存在抵触的。
尽管咱们能够在 .eslintrc.js
引入相干插件进行配置,使其当 Prettier 规定不合乎 ESLint 规定时进行报错揭示,但没有解决咱们的痛点,它须要咱们手动去修复。
还有,总是可能会存在先执行 ESLint,再进行 Prettier 的状况。所以我就想着整合这个脚本,使其依照咱们预期方向走:当两者有抵触的状况时,采纳 ESLint 的规定。
残缺脚本如下:
{
"scripts": {
"test": "echo \"Error: no test specified\"&& exit 1",
"eslint": "eslint ./ --ext .js",
"eslint:fix": "eslint --fix ./ --ext .js",
"prettier:fix": "prettier --config .prettierrc.js --write'./**/*.{js,css,less,scss,json}'","prettier:wxss":"gulp wxss","prettier:acss":"gulp acss","prettier:wxss:acss":"gulp all","format:all":"npm-run-all -p prettier:wxss:acss prettier:fix -s eslint:fix"
}
}
2. 装置 husky
$ yarn add --dev husky@4.3.0
在 package.json
增加配置,使其在进行 git commit -m 'xxx'
代码提交时,进行格式化操作,以保障咱们提交的代码是不丑的。
如果过程中呈现谬误(如 ESLint 校验不通过),将会进行 commit
操作,即 pre-commit
返回非零后果以退出。
它能够通过 git commit --no-verify
命令进行疏忽。
// package.json
{
"husky": {
"hooks": {"pre-commit": "yarn run format:all"}
}
}
3. 看成果
咱们轻易批改一个文件,而后进行提交。如图,能够看到是依照预期执行的,好了。
四、lint-staged
看到下面的后果,仿佛一切顺利。但没有完 …
从上图咱们看进去,咱们只提交了 一个文件 的变动,然而它对 所有文件 进行了扫描,这里是存在体验性问题的。
如果咱们有 N 多个暂存文件,那么每当咱们 git commit
一次就所有查看所有文件一遍,这导致咱们的体验十分不好,过程很慢,显然不是咱们想要的。
那么如何解决呢?咱们须要用到它 ???? lint-staged。
$ yarn add --dev lint-staged@10.3.0
自 v3.1 版本开始,能够有多种不同的形式进行配置,这里不多说。
在我的项目根目录创立一个 .lintstagedrc.js
的配置文件,而后通过 --config
或者 -c
指定。
// package.json
{
"husky": {
"hooks": {"pre-commit": "lint-staged --config .lintstagedrc.js"}
}
}
// .lintstagedrc.js
const path = require('path')
module.exports = {'*.js': ['prettier --config .prettierrc.js --write', 'eslint --fix --ext .js'],
'*.json': 'prettier --config .prettierrc.js --write',
'*.wxss': absolutePaths => {
// 获取相对路径
// const cwd = process.cwd()
// const relativePaths = absolutePaths.map(file => path.relative(cwd, file))
// return `gulp wxss --path ${relativePaths.join(' ')}`
return 'gulp wxss'
},
'*.acss': 'gulp acss'
}
留神,咱们不将门路作为命令调用时的参数传递。这一点很重要,因为 lint-staged 将为咱们实现这一点。
lint-staged
采纳的是 glob
匹配模式。从下面的配置中,通过匹配不同的文件类型执行相应的操作。
* 对于 lint-staged
相干应用阐明,倡议查看官网文档或者较瘦的这篇文章,我就不再详说。
不晓得有没有人好奇,下面
lint-staged
配置文件中,我在匹配.wxss
文件时采纳的是函数模式。其实这里是存在一个问题没解决的,就是在提交
.wxss
暂存文件时,不是只解决该.wxss
文件,而是将我的项目所有的.wxss
文件(蕴含未提交至暂存区的.wxss
文件)。起因大略如下:
1️⃣ 在后面我介绍了,因为 Prettier 没有解析器去解决.wxss
扩展名的文件,所以咱们应用了 Gulp.js 通过转换文件类型的形式去解决。而对应 Gulp 工作是匹配以后我的项目下所有.wxss
文件的,应用gulp.dest(__dirname)
是失常导出到源文件门路下。2️⃣ 依照
lint-staged
的思维,只解决提交的暂存文件。意味着咱们在执行gulp wxss
工作时应该要传递一个文件门路,而后再批改wxssPrettier
工作,使其既能匹配所有的,也能够匹配个别或多个的(而非所有).wxss
文件。而后我尝试了很多几种办法,都没能失去预期成果。3️⃣ 我踩坑思路大抵是:在执行
gulp wxss
时传递一个或者多个门路参数(如上配置文件正文局部),通过process.argv
获取 NPM 脚本参数,接着在wxssPrettier
工作中对获取的参数做解决,往gulp.src()
传递一个数组,到这来我感觉思路应该是没错的。然而事实是残暴的,在gulp.dest()
时导出的门路总是不对,所有的.wxss
文件都被导出到我的项目根目录下了,这显然不是咱们想要的后果。4️⃣ 目前我还没找到更好的解决方案,欢送大佬们赐教。
就是因为这个问题,我感觉我这个 wechat_applet_demo 还不是很完满(我有强迫症),若后续有解决方案了,会回来更新的。
至此
到这里根本就完结了,但可能还会退出 Commit Message 提交阐明的标准,因为一个清晰明了的提交阐明,能够让人很分明本次代码提交的目标或者解决了什么具体问题。目前应用最广的应该是 Angular 标准了,比拟正当和系统化,而且有配套的工具。能够看下这篇文章 git commit 标准指南。
若有不足之处,欢送留言斧正。
The end.