前端代码检查与代码规范

一、背景

本篇介绍的是如何做到在代码提交前，统一团队代码风格，检查代码质量，并修复一些低级错误。最终期待项目中的开发人员提交的代码都符合代码规范、风格统一。

二、组合技

Git Hook + lint-staged + Prettier + ESLint，先介绍最终实现，具体每个模块的作用和配置后面有各自的介绍。

2.1 实现步骤

准备好待提交的代码
git add . 添加到暂存区
执行 git commit
husky注册在git pre-commit的钩子调起 lint-staged
lint-staged 取得所有被提交的文件依次执行写好的任务（ Prettier + ESLint）
如果有错误（没通过 ESLint 检查）则停止任务，等待下次commit，同时打印错误信息
成功提交

2.2 安装包

npm i --save-dev husky lint-staged prettier

npm i --save-dev eslint babel-eslint eslint-plugin-react

2.3 模块配置

2.3.1 `.eslintrc`

{
  "env": {
    "browser": true,
    "es6": true
  }
  "eslint": "recommended",
  "parserOptions": {
    "ecmaFeatures": {
      "jsx": true,
      "impliedStrict": true
    }
  },
  "plugin: react",
  "rules": {
    "quotes": [
      "error",
      "single"
    ]
  }
}

2.3.2 `.prettier.js`

module.exports = {
  // 一行最多 100 字符
  printWidth: 100,
  // 使用 4 个空格缩进
  tabWidth: 4,
  // 不使用缩进符，而使用空格
  useTabs: false,
  // 行尾需要有分号
  semi: false,
  // 使用单引号
  singleQuote: true,
  // 对象的 key 仅在必要时用引号
  quoteProps: 'as-needed',
  // jsx 不使用单引号，而使用双引号
  jsxSingleQuote: false,
  // 末尾不需要逗号
  trailingComma: 'none',
  // 大括号内的首尾需要空格
  bracketSpacing: true,
  // jsx 标签的反尖括号需要换行
  jsxBracketSameLine: false,
  // 箭头函数，只有一个参数的时候，也需要括号
  arrowParens: 'always',
  // 每个文件格式化的范围是文件的全部内容
  rangeStart: 0,
  rangeEnd: Infinity,
  // 不需要写文件开头的 @prettier
  requirePragma: false,
  // 不需要自动在文件开头插入 @prettier
  insertPragma: false,
  // 使用默认的折行标准
  proseWrap: 'preserve',
  // 换行符使用 lf
  endOfLine: 'lf'
}

2.3.3 `package.json`

{
  ...
  "husky": {
    "hooks": {
      "pre-commit": "lint-staged"
    }
  },
  "lint-staged": {
    "src/**/*.{js,jsx}": [
      "prettier --write",
      "eslint --fix",
      "git add ."
    ]
  },
  ...
}

2.3.4 运行结果

上面的配置只是一种组合方式的举例，还可以自由组合为多种检查方式，这里就不一一列举了。后面是对各个模块的介绍，感兴趣可以继续阅读。

二、Prettier 的介绍和配置

2.1 Prettier 是什么？

Prettier 作为强大的代码格式化工具，能够完全统一你和同事的代码风格 (这真的很重要...)
同时结合 ESLint 规则和自身配置的规则，进行代码自动格式化
Prettier 只会做代码风格的统一，并不会检查代码规范，关于代码规范的检查应该交给 ESLint

2.2 Prettier 的必要性

简单的配置即可自动格式化并统一代码风格
减少代码 CR 的时间，不再关心格式问题
避免肉眼检查代码格式，减少代码提交次数
缓解强迫症的焦虑

2.3 如何配置？

2.3.1 在编辑器中安装插件

目前开发使用的是 vscode 编辑器，在扩展中查找 Prettier - Code formatter 插件安装后即可使用。不同编辑器的插件
安装后打开需要格式化的文件，按照下面的方式可以格式化整个文件或者格式化选定的代码片段

1. CMD + Shift + P -> Format Document
OR
1. Select the text you want to Prettify
2. CMD + Shift + P -> Format Code

[图片上传失败...(image-4acd90-1575447043750)]

2.3.2 使用配置文件

创建规则文件：在根目录创建 .prettierrc 文件（支持 json 配置格式）或者创建一个 .prettierrc.js 配置文件
在 package.json 文件的 scripts 中添加对应的代码

{
  ...
  "scripts": {
    "format": "prettier --write 'src/**/*.{js,jsx,css,less}'",
    ...
  },
  ...
}

在控制台执行 npm run format 即可自动格式化配置范围内的所有文件

三、ESLint 的介绍和配置

3.1 ESLint 是什么？

ESLint 是一个代码检查工具，它能够被开发者灵活的配置，使其能够满足制定好的代码规范的要求，并且在编码过程中实时检测输入的代码，对于不符合代码规范的代码警告或报错。

3.2 ESLint 的必要性

编码阶段及时发现问题
保证代码遵循最佳实践
统一代码编写规范

3.3 如何使用

3.3.1 配置方法

配置注释 : 使用JavaScript注释将配置信息直接嵌入到文件中
配置文件 : 使用JavaScript，JSON或YAML文件指定配置信息

3.3.2 配置文件说明

文件格式

JavaScript : 使用.eslintrc.js并导出包含您的配置的对象。
YAML : 使用.eslintrc.yaml或.eslintrc.yml定义配置结构。
JSON : 用于.eslintrc.json定义配置结构。
使用.eslintrc，可以是 JSON 或 YAML。
package.json : eslintConfig在你的package.json文件中创建一个属性并在那里定义你的配置。

环境 :

脚本设计运行的环境。每个环境都带有一组预定义的全局变量。

"env": {
  "browser": true,
  "node": true
}

全局变量 :

脚本在执行期间访问的其他全局变量。

"globals": {
  "React": true,
  "MtaH5": true,
  "TencentGDT": true
}

解析器选项 :

ESLint允许你指定你想要支持的JavaScript语言选项。默认情况下，ESLint需要ECMAScript 5语法。您可以覆盖该设置，以使用解析器选项启用对其他ECMAScript版本以及JSX的支持。

"parserOptions": {
  "ecmaVersion": 6,
  "sourceType": "module", // 设置为`"script"`（默认）或者`"module"`您的代码位于ECMAScript模块中。
  "ecmaFeatures": { // 一个对象，指示您想要使用哪些其他语言功能
    "jsx": true, // 启用JSX
    "impliedStrict": true // 启用全局严格模式
  }
},

插件

要在配置文件中配置插件，请使用plugins包含插件名称列表的密钥。该eslint-plugin-前缀可以从插件名称被省略。

"plugins": [
  "react",
  "eslint-plugin-react"
]

扩展

扩展就是直接使用别人已经写好的 lint 规则，rules 属性中配置的规则都是基于这个规则之上配置的

"extends": [
  "standard"
  "eslint:recommended",
  "plugin:react/recommended"
],

推荐的扩展配置：

standardjs、airbnb、eslint-config-alloy

规则 :

ESLint 附带有大量的规则。你可以使用注释或配置文件修改你项目中要使用的规则。要改变一个规则设置，你必须将规则 ID 设置为下列值之一

"off" 或 0 : 关闭规则
"warn" 或 1 : 开启规则，使用警告级别的错误(不会导致程序退出)
"error" 或 2 : 开启规则，使用错误级别的错误(当被触发的时候，程序会退出)

"rules": {
  "strict": 2,
}

3.3.3 如何检测

将运行命令添加到 package.json 的 scripts 脚本中，设置对 src 目录下的文件进行检查

{
 ...
  "scripts": {
    "lint": "eslint ./src"
    "lintFix": "eslint ./src --fix"
  },
  ...
}

在控制台运行如下命令：

// 代码检查
npm run lint
// 代码检查并修复
npm run lintFix

四、Git Hook 的介绍和配置

4.1 Git 钩子

和其它版本控制系统一样，Git 能在特定的重要动作发生时触发自定义脚本。这里介绍的是提交工作流钩子

4.1.1 `pre-commit`

钩子在键入提交信息前运行
用于检查即将提交的快照
如果该钩子以非零值退出，Git 将放弃此次提交
可以用 git commit --no-verify 来绕过这个环节
可以利用该钩子，来检查代码风格是否一致

4.1.2 `prepare-commit-msg`

钩子在启动提交信息编辑器之前，默认信息被创建之后运行
允许你编辑提交者所看到的默认信息

4.1.3 如何配置

将配置添加到 package.json 中，执行命令添加到 scripts 脚本中：

{
  "scripts": {
    "lint": "eslint ./ --cache --ignore-pattern .gitignore",
    "precommit-msg": "echo 'Pre-commit checks...' && exit 0"
  },
  "pre-commit": [ "precommit-msg", "lint" ],
  "devDependencies": {
    "eslint": "^2.12.0",
    "pre-commit": "^1.1.3"
  }
}

4.2 Husky

在我们的 package.json 中配置 husky，并且在对应的 git hook 阶段来执行对应的命令。因此，不用繁琐的去配置 git hook 阶段的脚本文件了。

{
  "husky": {
    "hooks": {
      "pre-commit": "npm test",
      "pre-push": "npm test"
    }
  }
}

五、lint-staged

lint-staged的作用是每次提交只检查本次提交所修改的文件，其中 staged 是 Git 里面的概念，指待提交区，使用 git commit -a，或者先 git add 然后 git commit 的时候，你的修改代码都会经过待提交区。

// package.json
{
  ...
  "scripts": {
    "precommit": "lint-staged", // git commit 执行这个命令，这个命令在调起 lint-staged
  },
  "lint-staged": {   // lint-staged 配置
    "src/**/*.{js,jsx}": [
      "prettier --write",
      "eslint --fix",
      "git add"
    ]
  },
  ...
}

六、总结

上面整理了一些项目实践过程中的方式和方法。方法的使用可以提高项目的质量。有规范的代码，一定程度可以减少问题的发生。代码的可读性也有所提高。