前言

在最近整理项目结构，并使用 husky 的 pre-commit 配合 lint-staged 来在提交前对代码进行检测代替原有的 eslint-loader时，发现自己和其他同事的理解有所不同，故成该文以作总结。

在开始之前我们将粗略探讨一我做这项工作的意义。

为什么我们需要 lint

总所周知在一个项目开发中，一套约定俗成的规范是极度有必要的，没有统一的开发风格我们在维护或者开发代码时的差异将导致维护困难性的指数型上升，扎根于业务的我等业务仔将苦不堪言 ??。

在刀耕火种的年代，这种规范全靠 code review ，或者更加简单的 全靠自觉 ，这显然是不怎么靠谱的，人皆有惰性（我不是不相信各位——但是事实如此嘛 ??），难免大家会觉得一个格式，不想改。所以后来出现了 eslint stylelint commitlint 等格式规范工具，让这种工作变得更加自动化和规范，但与之同时也诞生了一些问题：

该在哪里进行检测

接入 lint 工具其实是相对比较简单的事情，只需要团队安装好依赖，引入需要的 config plugin等，然后在既有的规则中（或者由插件提供的规则）找到适合自己团队的规则配置，就可以通过简单的 npm script 对自己的项目进行 lint 检测，但是这个仅仅是通过手动输入命令达到的而已，我们应该怎么让其自动进行呢？

对于这一点，当前常用的有两种方式：

• loader
• git hooks

loader 通常作为前置的处理，在 webpack 配置中增加 loader 可以在开发过程中发现许多书写时的 lint 错误，帮助开发者及时更正，但是其痛点很明显，因为这个过程存在于编译时，也就是说我们每改动一行代码，就会触发一次 loader 检测，这不光会让开发中的我们很蛋疼，频繁面对屏幕上的报错，拖慢编译速度，更甚至一旦你在线上环境的编译配置中没有移除该 loader ，这次的编译将浪费大量的时间在你开发时已经经历了不知道多少次的 lint 检测上。

loader 编译流程图

而 git hooks 完全没有该问题，通过放弃实时的检测而在 commit 之前进行 lint 检测，可以让开发中的我们更关心业务，同时也能保线上仓库中代码的格式统一性（毕竟你不不改提交不上来 ??）。

git hooks 编译流程图

通过一些权衡，我放弃了频繁的检测而选择了一劳永逸的 git hooks，来在提交时进行 lint 检测。

该检测哪些内容

不管是使用 npm script git hooks loader 还是其他工具，我们通常都是进行的全量检测(loader的触发总是在编译时)，然而有时候我们并没有对全局的内容做过多的处理，有时候明明只是改了一行代码，却发现检测出了一大片的其他无关文件的lint错误，这无疑让人头大，我们的目的可是让我们更关注于业务，这显然是不 OK 得。

我们需要检测我们需要关注的内容，简单而言就是我们提交的内容。

冲突

为了解决上面的问题，我们引入了 lint-staged ，其可以做到只对你 commit 的内容进行检测（对其感兴趣的同学可以点击这里大概了解一下这个工作流程。）

但是这时候我和同事的冲突就出现了，我们对 lint-staged 的使用出现了不同的观点，对我而言，我更关注的是 lint，而我的同事更关注的是 规范，这之中有和不同呢？

lint

受一个之前的同事影响，在我的看来，lint 只要做到检测的目的就好了，其本质作用不光是规范，更应该让人接受和学会这些规范，达到就算有一天不再依赖工具也能写出符合规则代码的目的，所以我让 lint-staged 只进行检测工作，而不自动修复这些错误，这些修正交由开发者执行。

规范

而我的同事认为，我们使用工具的作用就是让代码的格式和风格统一，我们应该更关注于业务，如果工具能够帮助我们修正风格，那我们就应该把这些工作完全交由工具去做，开发人员做好开发工作就好（顺道一提，最开始的我也是这种想法 ??）。

结局

综合考量之后，我决定还是同意了同事的观点，不光是因为项目工期紧，时间段，还有整个流程长度问题（完全不是因为我个人最开始是坚定的偷懒党），可是这个问题还是值得我们沉思：在项目规范流程的推进中，我们到底是该选择人适应规则，还是让代码适应规则呢？

不知诸君何解。