lint自动化代码检查背景之前开发过程中遇到过一些坑，并产生了大量的线上崩溃，遇到过的一些问题如下：有些颜色值是通过

背景

之前开发过程中遇到过一些坑，并产生了大量的线上崩溃，遇到过的一些问题如下：

有些颜色值是通过后端下发的，但是在使用 Color.parseColor() 方法时，如果后端返回的不是标准的颜色格式，就会 crash。
在 AndroidManifest.xml 文件中对一个 Activity 同时设置方向和透明主题时，在 Android 8.0 手机上会 crash。

但是这些类似的错误并不是每位开发者都会知道，所以即使一个人遇到过，以后可能还会有人犯同类的错误。

因此，为了避免后人踩相同的坑，我们可以利用 Lint 检查工具，对大家写的代码进行检查，针对可能会产生问题的代码进行友好的提示，并在打包中的 Lint 检查过程中禁止编译通过。

在使用现代化工具的基础上，如何尽可能发挥其能量？在必要的情况下，如何开发适合自己团队需求的工具？

Prettier

英文单词 prettier 是 pretty 的比较级，pretty 译为“漂亮、美化”。顾名思义，Prettier 这个工具能够美化我们的代码，或者说格式化、规范化代码，使其更加工整。它一般不会检查我们代码具体的写法，而是在“可读性”上做文章。目前支持包括 JavaScript、JSX、Angular、Vue、Flow、TypeScript、CSS（Less、SCSS）、JSON 等多种语言、数据交换格式、语法规范扩展。总的来说，它能够将原始代码风格移除，并替换为团队统一配置的代码风格。虽然几乎所有团队都在使用这款工具，这里我们还是简单分析一下使用它的原因：

构建并统一代码风格
开发者可以完全聚焦业务开发，不必在代码整理上花费过多心思
方便，低成本灵活接入，并快速发挥作用
清理并规范已有代码
减少潜在 Bug

Prettier 也可以与编辑器结合，在开发者保存后立即进行美化，也可以集成到 CI 环境中，或者 Git pre-commit 的 hook 阶段。比如使用 pretty-quick：

yarn add prettier pretty-quick husky --dev

package.json 中配置：在 husky 中，定义 pre-commit 阶段，对变化的文件运行 Prettier，--staged 参数表示 pre-commit 模式：只对 staged 的文件进行格式化。

{
    "husky": {
        "hooks": {
            "pre-commit": "pretty-quick --staged"
        }
    }
}

ESLint

以 ESLint 为代表的 Linter。Code Linting 表示基于静态分析代码原理，找出代码反模式的过程。多数编程语言都有 Linter，它们往往被集成在编译阶段，完成 Coding Linting 的任务。

对于 JavaScript 这种动态、宽松类型的语言来说，开发者更容易犯错。由于 JavaScript 不具备先天编译流程，往往会在运行时暴露错误，而 Linter，尤其最具代表性的 ESLint 的出现，允许开发者在执行前发现代码错误或不合理的写法。

所有规则都插件化
所有规则都可插拔（随时开关）
使用 Espree 进行 JavaScript 解析
使用 AST 分析语法

那么如何声明并应用规则呢？在根目录中打开 .eslintrc 配置文件，我们在该文件中加入：

{
    "rules": {
        "semi": ["error", "always"],
        "quote": ["error", "double"]
    }
}

semi、quote 就是 ESLint 规则的名称，其值对应的数组第一项可以为：off/0、warn/1、error/2，分别表示关闭规则、以 warning 形式打开规则、以 error 形式打开规则。

还会在 .eslintrc 文件中发现：选取其他规则集合，比较出名的有：

Google JavaScript Style Guide
Airbnb JavaScript Style Guide

"extends": "eslint:recommended"

.eslintrc 文件，其实它主要由六个字段组成

module.exports = { 
   env: {}, 
   extends: {}, 
   plugins: {}, 
   parser: {}, 
   parserOptions: {}, 
   rules: {},
}

env：表示指定想启用的环境。
extends：指定额外配置的选项，如 ['airbnb'] 表示使用 Airbnb 的 Linting 规则。
plugins：设置规则插件。
parser：默认情况下 ESLint 使用 Espree 进行解析。
parserOptions：如果将默认解析器更改，需要制定 parserOptions。
rules：定义拓展并通过插件添加的所有规则。

.eslintrc 文件我们采用了 .eslintrc.js 的 JavaScript 文件格式，此外还可以采用 .yaml、.json、yml 等格式。如果项目中含有多种配置文件格式，优先级顺序为：

.eslintrc.js
.eslintrc.yaml
.eslintrc.yml
.eslintrc.json
.eslintrc
package.json

Linter VS Prettier

格式化规则（Formatting Rules）

这类“格式化规则”典型的有 max-len、no-mixed-spaces-and-tabs、keyword-spacing、comma-style，它们“限制一行的最大长度”“禁止使用空格和 Tab 混合缩进”等代码格式方面的规范。事实上，即便开发者写出的代码违反了这类规则，如果在 Lint 阶段前，先经过 Prettier 处理，这些问题会在 Prettier 阶段被纠正，因此 Linter 不会抛出提醒，非常省心，这也是 Linter 和 Prettier 重叠的地方。

代码质量规则（Code Quality Rules）

“代码质量规则”类似 no-unused-vars、no-extra-bind、no-implicit-globals、prefer-promise-reject-errors，它们限制“声明未使用变量”“不必要的函数绑定”等代码写法规范。这个时候，Prettier 对这些规则无能为力，而这些规则对于代码质量和强健性至关重要，还是需要 Linter 来保障的。

husky 和 lint-staged

husky 就是 Git 的一个钩子，在 Git 进行到某一时段时，可以交给开发者完成某些特定的操作。比如每次提交（commit 阶段）或者推送（push 阶段）代码时，就可以执行相关 npm 脚本。需要注意的是，在整个项目上运行 Lint 会很慢，我们一般只想对更改的文件进行检查，此时就需要使用到 lint-staged。比如如下代码：

"scripts": {
    "lint": "eslint --debug src/",
    "lint:write": "eslint --debug src/ --fix",
    "prettier": "prettier --write src/**/*.js"
},
"husky": {
    "hooks": {
        "pre-commit": "lint-staged"
    }
},
"lint-staged": {
    "*.(js|jsx)": ["npm run lint:write", "npm run prettier", "git add"]
},

表示在 pre-commit 阶段对于 js 或者 jsx 后缀且修改的文件执行 ESLint 和 Prettier 操作，通过之后再进行 git add 添加到暂存区

lint自动化代码检查

背景

Prettier

ESLint

Linter VS Prettier

husky 和 lint-staged

汇总