关于eslint:使Prettier一键格式化WXSS下集

上一篇文章介绍了如何一键格式化 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.