前端代码检查与代码规范

一、背景

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

二、组合技

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 使用配置文件

1. 创建规则文件：在根目录创建 .prettierrc 文件（支持 json 配置格式）或者 创建一个 .prettierrc.js 配置文件

2. 在 package.json 文件的 scripts 中添加对应的代码

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

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

三、ESLint 的介绍和配置

3.1 ESLint 是什么？

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

3.2 ESLint 的必要性

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

3.3 如何使用

3.3.1 配置方法

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

3.3.2 配置文件说明

1. 文件格式

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

2. 环境 :

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

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

3. 全局变量 :

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

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

4. 解析器选项 :

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

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

5. 插件

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

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

6. 扩展

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

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

推荐的扩展配置：

standardjs、airbnb、eslint-config-alloy

7. 规则 :

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"
    ]
  },
  ...
}

六、总结

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

作者：SeaDM
链接：https://juejin.im/post/5de75a53f265da33bc57bf72