前言如果一个项目涉及到多人协作，由于每个人的代码编写习惯和风格不同，如果没有统一的规范就会很混乱。代码的可维护性大大降低。因此，现代工程的一个组成部分就是代码检查（CodeLinting，简称Lint）来保证代码规范的一致性。代码规范一致性的保证也有很多，比如：ESLint、prettier、SCSSint、JSONLint等。更完整的列表可以看GitHub官方的Lint工具列表[1]本文不会介绍各个工具的使用方法，但是如何将这些工具串在一起以构建代码检查工作流。最简单的方法最简单的方法就是在每次提交代码之前先处理一下。以eslint为例：eslintsrc/**/*.jsgitadd.gitcommit-m'feat:anewfeature'这种方法有两个致命的缺点：如果检测工具很多，需要多次处理。很容易忘记。使用脚本来解决问题。如果检测工具较多，需要多次处理脚本，即package.json中的脚本。比如需要同时使用prettier和eslint，可以自定义一个脚本，运行脚本后提交代码：{"scripts":{"lint":"prettier--write&eslintsrc/**/*.js"}}那么每次提交代码之前，只需要：npmrunlintgitadd.gitcommit-m'feat:anewfeature'使用哈士奇（Husky）解决容易遗忘的问题虽然我们用脚本解决了很多检查工具的问题，但是还有一个很容易忘记，怎么解决呢？解决方案是通过哈士奇。原理其实是通过githooks[2]来解决的。Husky是一个让githooks更容易使用的工具。当您提交或推送时，您可以使用它来整理您的提交消息、运行测试、lint代码等。Husky支持所有Git钩子[3]。”这是哈士奇官网的一句话，用来形容哈士奇能做什么。那怎么解决呢？接下来介绍一下husky的使用方法：1.安装huskynpminstallhusky--save-dev启用githooksnpx执行完huskyinstall后，文件根目录下会多出一个.husky文件夹：安装后Automatically启用githooksnpmset-scriptprepare"huskyinstall"然后你可以看到package.json添加了一个脚本//package.json{"scripts":{"prepare":"huskyinstall"}}注意一点：Yarn安装不支持prepare生命周期，需要将prepare改成postinstall。详见官网[4]2.创建precommithooknpxhuskyadd.husky/pre-commit"npmrunlint"gitadd.husky/pre-commit执行后会有pre-commit.husky目录中的文件。里面的npmrunlint就是这个钩子要执行的命令。如果以后要更改，也可以直接修改这个文件。这时候会先自动执行commit。npm运行lint，然后提交。但这解决了上述问题。当项目很大时，会出现一些问题。比如每次lint都是整个项目的文件，文件太多会导致运行时间过长。另外如果项目后期接这个lint的话，lint命令可能会报很多错误，全部改掉可能会有问题。lint-stadge只有lint变化是基于以上痛点，出现lint-stadge。它的解决方案是只检查本次提交修改的问题（指的是git暂存区[5]中的东西），这样每次的lint量都比较少，满足我们的需求。如果不知道暂存区，需要复习一下git知识。简单的说，gitadd或者gitcommit-a的部分代码会先放到暂存区。lint-staged的使用方法如下：1.安装npminstall-Dlint-staged2。修改package.json配置{"lint-staged":{"src/**/*.js":"npmrunlint"}}3.setprecommittorunlint-staged完成以上配置后，就可以通过npxlint-staged手动查看暂存区的文件了。manual永远不是manual，automatic的方法就是把npxlint-staged设置成hook。npxhuskyadd.husky/pre-commit"npxlint-staged"或者直接改.husky下的precommit文件。至此，我们的代码审查工作流程已经完成。gitcommit的时候，会自动回去帮我们运行check脚本，只检查我们这次提交的代码。参考配置react+less项目的lint-staged配置可以参考：{"lint-staged":{"**/*.less":"stylelint--syntaxless","**/*.{js,jsx,ts,tsx}":"eslint--ext.js,.jsx,.ts,.tsx","**/*.{js,jsx,tsx,ts,less,md,json}":["更漂亮--write","gitadd"]}}总结在这篇文章中，作者并没有详细介绍每个lint工具的使用和配置，也没有直接给出构建代码检查工作流的最佳实践，而是从最原始的stepbystep使用githooks,husky,lint-staged等各种工具推导出最终的解决方案。因为我觉得如果你不使用每个工具来解决什么问题，为什么需要它解释清楚，而是直接给出一个最佳实践SOP，这样就会变成一个无脑的copyexecutor，当你找不到这个的时候看了这篇文章，你可能不知道如何下手，但是当你知道自己遇到了什么问题，如何解决的时候，你也可以从0配置一份。参考使用husky和lint-staged构建超级流畅代码检查工作流程[6]husky官网[7]参考资料[1]Lint工具列表：https://github.com/collections/clean-code-linters[2]githooks：https://git-scm.com/book/zh/v2/%E8%87%AA%E5%AE%9A%E4%B9%89-Git-Git-%E9%92%A9%E5%AD%90[3]allGithooks：https://git-scm.com/docs/githooks[4]官网：https://typicode.github.io/husky/#/?id=yarn-2[5]git暂存专区：https://www.4e00.com/git-zh/1-introduction.html#-ReHMS4ux[6]使用husky和lint-staged构建超级流畅的代码检查工作流程：https://segmentfault.com/a/1190000009546913[7]哈士奇官网：https://typicode.github.io/husky/#/
