用 husky 和 lint-staged 构建超溜的代码检查工做流

具有基本工程素养的同窗都会注重编码规范，而代码风格检查（Code Linting，简称 Lint）是保障代码规范一致性的重要手段，你的工做流中有 Lint 环节么？有的话你用的爽么？你在团队中推广过 Lint，可是你们都不买帐？到底是为啥？

Lint 是什么？

探讨怎么作以前，咱们颇有必要给 Lint 来个清晰、准确的定义，wikipedia 的定义以下：

In computer programming, lint is a Unix utility that flags some suspicious and non-portable constructs (likely to be bugs) in C language source code; generically, lint or a linter is any tool that flags suspicious usage in software written in any computer language. The term lint-like behavior is sometimes applied to the process of flagging suspicious language usage. Lint-like tools generally perform static analysis of source code.

简单来讲，Lint 就是对代码作静态分析，并试图找出潜在问题的工具，实战中咱们也用 Lint 来指使用工具的过程。

为何要 Lint？

使用 Lint 会有什么好处呢？在我看来至少具备以下 3 点：

• 更少的 Bug，剑桥大学的研究发现，全世界每一年由于软 Bug 形成的经济损失约 3120 亿美金；

• 更高的开发效率，工程师平均会花掉 50% 的工做时间定位和解决各类 Bug，其中不乏那些显而易见的低级错误，而 Lint 很容易发现低级的、显而易见的错误；

• 更高的可读性，代码可读性的首要因子是“表面文章”，表面上看起来乱糟糟的代码一般更难读懂；

能够绝不客气的说，若是你不作 Lint，就是在浪费本身的时间，浪费公司的资源。既然作 Lint 的预期效果很好？该怎么作呢？

提交后 Lint：反馈链条太长？

说到怎么作，多数人会天然而然的想到各类 Lint 工具，目前社区中针对各类语言都开发了 Lint 工具，前端能用到的就有大把：ESLint、Standard、SCSSLint、JSONLint、HTMLHint 等。GitHub 官方出品的 Lint 工具列表 也是个很是不错的参考。

不少同窗选择在持续集成阶段（后文用 CI 代称）作 Lint，好比使用远程的 Git Hooks 来触发。可是从实际的经从来看，这种作法的反馈链条一般以下：

代码提交 --> 发现问题(远程) --> 修复问题 --> 从新提交 --> 经过检查(远程)

整个过程可能会浪费掉你很多时间，毕竟 CI 过程一般不只是在作 Lint，若是你是那种不知道本身时间天天都去哪儿了的工程师，能够反思下本身或者团队的工做流是不是这样。而且，请相信我，你不是少数人。

你有没有这样的经历：吭哧吭哧写了几天代码，各类验收都经过了，最后被 CI 拒绝，竟是由于你的代码中少加了一个逗号，这时候心情简直崩溃到没法形容：

从 GitHub 上各类修复 Lint 的提交数量不难发现工程师在修复 Lint 问题上浪费的时间，好比搜索 "fix lint"，多达 45W 次提交：

再好比搜索 “fix indent”，多达 226W 次提交，是否是很触目惊心？

只在 CI 流程作 Lint 的缺点也是显而易见的：

• Lint 在整个开发工做流中的反馈链条太长，浪费时间、注意力和资源，最致命的；

• CI 流程搭建成本比较高，即便有各类 CI 服务，步骤也仍是比较繁琐；

咱们该怎么改进？

提交前 Lint：错误信息不相关？

为了缩短 Lint 的反馈链条，把 Lint 挪到本地是最有效的办法。常见作法是使用 husky 或者 pre-commit 在本地提交以前作 Lint。

使用 husky 的具体作法以下：

首先，安装依赖：

npm install -D husky
yarn add --dev husky

而后修改 package.json，增长配置：

{
  "scripts": {
    "precommit": "eslint src/**/*.js"
  }
}

最后尝试 Git 提交，你就会很快收到反馈：

git commit -m "Keep calm and commit"

可是在遗留代码仓库上工做的同窗很快会遇到新的问题，开启 Lint 初期，你可能会面临成千上万的 Lint Error 须要修复。部分同窗对下面这个图可能并不陌生：只改了文件 A，可是文件 B、C、D 中也有大量错误。

把整个仓库都格式化不失为一种选择，可是实际上须要很大的勇气。多数人在项目中运用新工具都但愿是渐进式的，而不是推到重来式的，由于相比而言，业务系统稳定是更重要的事情。简单的把 Lint 挪到本地，反馈链条是缩短了，可是面对每次改动，工具仍是给出了太多不相关的信息，这无疑与小步快跑的互联网节奏是相违背的。

该怎么破？

只 Lint 改动的：66666

若是把 Lint 挪到本地，而且每次提交只检查本次提交所修改的文件，上面的痛点就都解决了。Feedly 的工程师 Andrey Okonetchnikov 开发的 lint-staged 就是基于这个想法，其中 staged 是 Git 里面的概念，指待提交区，使用 git commit -a，或者先 git add 而后 git commit 的时候，你的修改代码都会通过待提交区。

lint-staged 用法以下：

首先，安装依赖：

npm install -D lint-staged
yarn add --dev lint-staged

而后，修改 package.json 配置：

{
  "scripts": {
    "precommit": "lint-staged"
  },
  "lint-staged": {
    "src/**/*.js": "eslint"
  }
}

最后，尝试提交的效果：

实际上，lint-staged 给了你提交前代码操做的更大自由度，好比使用下面的配置，自动修复错误：

{
  "scripts": {
    "precommit": "lint-staged"
  },
  "lint-staged": {
    "src/**/*.js": ["eslint --fix", "git add"]
  }
}

或者使用下面的配置，自动格式化代码（谨慎使用）：

{
  "scripts": {
    "precommit": "lint-staged"
  },
  "lint-staged": {
    "src/**/*.js": ["prettier --write", "git add"]
  }
}

此外，lint-staged 和 prettier 已经集成到 create-react-app 中了。你是否是也应该好好打磨下本身的 Lint 工做流了？

总结

有人说前端攻城狮是世界上最奇怪的动物，提交代码时用 prettier 把代码排版的很美观，但部署上线时又使用 uglify 把代码压缩的连亲妈都不认了，事实是，若是咱们写出来的代码原本就很丑陋，就根本不须要用 uglify。但愿读到这里的你能把 Lint 工做流打磨到极致，把更多时间专一在解决真正的问题上，成为真正高效的工程师。

One More Thing

本文做者王仕军，商业转载请联系做者得到受权，非商业转载请注明出处。若是你以为本文对你有帮助，请点赞！若是对文中的内容有任何疑问，欢迎留言讨论。想知道我接下来会写些什么？欢迎订阅个人掘金专栏或知乎专栏：《前端周刊：让你在前端领域跟上时代的脚步》。