关于前端:从项目规范eslint-prettier到自动化配置

前言：为什么须要我的项目标准

咱们学习编程的形式各有不同，对于常识的了解也各有不同，在一天天的编程过后，每个人都养成了本人的代码习惯和了解。

代码习惯和了解的差别，导致了团队中会呈现各种各样的“标准”代码。在你查看本人的代码时，你可能会感觉本人的代码看起来比拟规范，只是有点乱。然而在团队成员查看你的代码时，他心里可能会这么想：wtf，他写的代码怎么是这个样子。这种格调的代码就如同是一个公司律师用 excel 标准主动格式化的沙拉食谱，看起来一点都不靠谱。

这种差异性导致了团队合作的效率低下，也影响了我的项目的健壮性和可维护性。所以，咱们须要对代码格调进行标准。这种标准不仅能够使代码格调放弃对立，并且能够在代码运行之前就检测出一些谬误和 bug，进步合作开发效率。

而前端开发人员最罕用的 Javascript 最后设计进去是只是为了解决一些简略的网页互动，是一种弱类型、基于原型的语言。

Javascript 领有其它语言所没有的灵活性，这种灵活性带来了代码效率的晋升，但相应也使得代码编写具备很大的随意性。另外 Javascript 的隐式类型转换规定凌乱，容许同名函数的反复定义，这就减少了代码中存在隐患的可能性。

冷笑话：Javascript 权威指南和 Javascript 语言精粹的厚度区别。

如果可能在代码提交测试之前发现这些潜在的谬误，就可能极大地加重测试人员的压力，缩小软件我的项目的除错老本。可是 Javascript 作为解释型语言，解释器被内嵌在对应的客户端，对此示意无能为力，这个工作只能由专用的代码查看工具实现。

在接下来，我会针对上述的这些问题开展讲述，首先介绍解决这些问题的工具，而后再介绍借助这项工具来解决团队标准和谬误预检问题的步骤办法，最初再用一行命令来整合这些简单的步骤，将应用门槛降到最低。

Eslint 和 Prettier

lint

lint 是最驰名的 C 语言工具之一，是由贝尔实验室 SteveJohnson 于 1979 在 PCC(PortableC Compiler) 根底上开发的动态代码剖析，个别由 UNIX 零碎提供。

lint 被用于查看 C 程序中潜在的谬误，包含（但不限于）可疑的类型组合、未应用的变量、不可达的代码以及不可移植的代码。lint 会产生一系列程序员有必要从头到尾仔细阅读的诊断信息。应用 lint 的益处是：

1. 它能够查看出被编译器漏掉的谬误;
2. 能够关联很多文件进行谬误的检查和代码剖析, 具备较弱小灵活性

lint 应该也算是 lint 界的老祖宗了。

Eslint

有个叫 Nicholas C. Zakas 的人在 2013 年推出了一个 Javascript 的 lint 工具，而 Javascript 也称作 ECMAScript（简称 ES），所以这个工具被叫做 ESlint。

ESLint 是在 ECMAScript/JavaScript 代码中辨认和报告模式匹配的工具，它的指标是保障代码的一致性和防止谬误。

Eslint 能够在运行代码前就发现一些语法错误和潜在的 bug，极大地加重测试人员的压力，缩小软件我的项目的除错老本。同时，Eslint 容许开发者通过 rules 定义本人的代码标准，所以非常适合用于制订团队代码标准。

Prettier

Prettier 是一款代码格式化工具，用于检测代码中的格局问题，比方单行代码长度、tab 长度、空格、逗号表达式等。在性能职责上，ESlint 偏差于把控我的项目的代码品质，而 Prettier 更偏差于对立我的项目的编码格调。

在 ESlint 推出 --fix 参数前，ESLint 并没有自动化格局代码的性能，要对一些格局问题做批量格式化只能用 Prettier 这样的工具。并且，Prettier 在代码格调的检测上比 ESlint 更全面，所以两者通常是联合在一起应用的。

常见的标准规范

在介绍标准之前，能够先应用 npm i eslint prettier -g 命令全局装置 eslint 和 prettier，在前面的教程中都会应用到这两个全局包。

ESlint 举荐的标准

ESlint 在默认状况下是不开启任何自定义规定校验，只对谬误的 ES5 语法和规范的语法错误进行检测，比方 const 这种 ES6 语法，还有莫名其妙的分号（如下图）。

当咱们在我的项目目录下新增 eslintrc.js 文件，并写入以下内容后，将会启用 ESlint 举荐的标准：

module.exports = {
  root: true,
  extends: 'eslint:recommended'
};

在 ESlint 的举荐标准中，会有一些内置的规定，比方定义后未应用的变量将会抛出谬误，应用常量作为循环条件也会抛出谬误（如下图）。

ESlint 的举荐标准能够防止掉一些谬误，比方上述两个谬误就能够在运行前被查看到并解决，更多具体标准请参考 ESlint Recommend。

standard

standard 是基于 ESlint Recommend 衍生进去的更严格的标准。这个标准和 recommended 大略有 88 处不同，次要是 recommended 很多都是 off, standard 是 error, 比方 单行代码块两边加空格 、 禁止应用分号结尾。

上面的代码在 recommended 标准下不会报错，而在 standard 标准中会报错。

recommended 标准

standard 标准

先应用 npm i standard eslint-plugin-standard eslint-config-standard -D 命令装置 standard 插件，而后在 eslintrc.js 文件中写入以下内容后，将会启用 standard 标准：

module.exports = {
  root: true,
  extends: ['standard']
};

standard 会比 recommended 更加严格，在代码格调上也做了一些限度。不过它的用户群体也是比拟多的，也不乏一些大家耳熟能详的。（如下图）

具体标准请参考 ESlint Standard。

airbnb

airbnb 标准是最严格的 ESlint 标准，列出上面几点比拟显著的区别：

1. 默认必须要分号，而 eslint 默认不增加分号
2. 不能应用 for 循环，举荐应用数组自带的 API 实现遍历工作。
3. 当你必须应用函数表达式（或传递一个匿名函数）时，应用箭头函数符号。

除了这些以外，还有更多严格的规定，能够查看 Airbnb 标准。

在我的项目中配置 Eslint + Prettier

因为 Eslint 和 Prettier 存在一些雷同的规定，当同一个规定设置不同时，就会呈现很诡异的景象：应用 prettier 格式化的代码，无奈通过 eslint 校验。

上面，咱们就以一份 前端代码标准 为例，为一个我的项目配置一套残缺的 ESlint + Prettier 标准。

配置 .eslintrc.js

咱们新建一个 eslintrc.js 文件，写入以下内容，作为咱们的初始化配置。（如下）

module.exports = {root: true // 示意该文件为根配置文件};

在上一章的示例代码中，咱们发现 eslint 默认只能辨认 es5 的语法，所以咱们先配置 env 属性，让 eslint 反对到 es6 语法，并且咱们设置环境为 browser（浏览器）或 node（如下）。

module.exports = {
  root: true,

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

  extends: 'eslint:recommended'
};

如果应用 standard 规范则不须要额定设置，standard 反对最新的 ECMAScript 个性。而实验性的个性，则须要增加 babel-eslint 解析器。

所以，这里咱们间接配置 standard 规范和 babel-eslint 解析器，再加上一些自定义规定后，最初配置的规定如下：

module.exports = {
  root: true,

  parserOptions: {
    parser: 'babel-eslint', // 解析一些最新的 es 语法
    sourceType: 'module'  // 模块为 ECMAScript 模块
  },

  extends: ['standard'], // 应用 standard 规范

  rules: {
    'no-debugger': 'error', // 禁止在代码中应用 debugger
    quotes: ['error', 'single'], // 单引号
    semi: ['error', 'always'] // 代码须要以分号结尾
  }
};

在 ESlint 标准文件配置实现后，咱们再来增加 Prettier 配置文件，新建 .prettierrc.js 文件，增加以下内容：

module.exports = {
  printWidth: 800, // 单行宽度限度
  tabWidth: 2, // tab 应用两个空格
  useTabs: false, // 不应用制表符缩进，应用空格缩进
  semi: true, // 代码须要分号结尾
  singleQuote: true, // 单引号
  bracketSpacing: true, // 对象左右两侧须要空格
  jsxBracketSameLine: false, // html 敞开标签换行
  arrowParens: 'avoid', // 单参数的箭头函数参数不须要括号
  proseWrap: 'never', // 参考 https://prettier.io/docs/en/options.html#prose-wrap
  trailingComma: 'none' // 参考 https://prettier.io/docs/en/options.html#trailing-commas
};

在配置实现后，咱们新建一个文件，测试一下成果。在 src 目录下新建文件 test.js，填入以下内容：

应用主动格式化

从下面能够看出，文件并不合乎咱们制订的 eslint 标准，咱们上面别离应用 eslint 格式化和 prettier 格式化性能来尝试修改。

首先，咱们在命令行输出 eslint --fix src/test.js，而后看看成果（如下图）

咱们能够看到，多余的空格被删除了，双引号被换成了双引号，赋值运算符的左右两侧也被加上了空格。

接下来，咱们先把文件还原，而后应用 prettier -w src/test.js 命令进行格式化，成果如下图：

从上图能够看出，因为咱们设置的 eslint 和 prettier 的规定统一，所以格式化后的文件也是高度类似的。

这样一来，咱们就实现了代码标准格局的对立。

vscode 插件

大家从下面的示例代码中能够看出，编写不合标准的代码会间接在编辑器中报出谬误，这是因为下面的示例代码应用 vscode 展现，并装置了一些插件来辅助开发。

上面，咱们就来介绍一下这些插件。

咱们先通过 vscode 装置 ESLint 插件（如下图）

在装置了 ESLint 插件后，插件会读取目录下的 eslint 配置文件，而后对代码中的谬误进行查看后提醒进去（如下图）。

如果咱们在 vscode 中设置了上面这个属性的话，在保留文件的时候将会主动格式化代码。（如下图）

上面，咱们能够再装置 Prettier 插件（如下图）。

在装置好插件后，应用键盘组合键 shift + command/ctrl + p 唤起设置，而后输出 Format Selection With... 后，按回车键，在选项中抉择 Prettier 即可（如下图）。

在设置实现后，应用组合键 shift + option/alt + f 即可实现对文件的格式化。

这两个插件还有更多的性能，大家能够自行摸索一下。

插件的三两事

如果你对 vscode 的插件比拟相熟，能够跳过本章节内容。

在 vscode 的插件装置过程中，有很多童鞋反馈过问题，这里给出一些常见问题的解决方案。

插件不工作

1. 全局装置 npm i eslint prettier -g
2. 装置好 vscode 插件后，重启 vscode
3. 如果还是不行的话，降级 vscode

插件未启用

新版 vscode 须要手动启用 eslint 插件，在右下角查看 eslint 工作状态，能够点击开启。（如下图）

启用后不工作

右下角查看 eslint 工作状态，点击会输入日志。（如下图）

依据输入日志，进行修复，比方上图就是短少对应插件，装置即可。

保留没有依照 eslint 的规定修复

这可能是因为你的 vscode 开启了保留主动格式化（代码格式化），先关上 首选项 > 设置，搜寻 format on save，而后敞开这个选项（如下图）

失常工作

失常工作的 eslint 和 prettier 插件状态如下图所示。

在提交时自动检测和格式化代码

在我的项目开发过程中，主动格式化并不总是让人安心的，因为并不是项目组的所有成员都会应用 vscode 插件来做主动格式化。

这样的状况会导致有一些不标准的代码被提交到服务端，仍然会造成团队标准不统一的问题，这个时候就须要用到提交时自动检测和格式化代码的性能。

接下来，咱们将应用 husky 来进行代码提交时的自动检测工作。

先应用 npm i husky -D 装置依赖，在依赖实现实现后，咱们须要应用上面这条命令初始化 husky（如下）

npx husky install && npx husky set .husky/pre-commit "npm run pre-commit"

下面的命令是初始化 git hook，在 git commit 之前会先执行 pre-commit 命令。

所以，咱们还须要在我的项目的 package.json 中，增加 pre-commit，这个命令运行时进行 eslint 检测（如下）。

"scripts": {"pre-commit": "eslint src"}

接下来，咱们运行 git add . 和 git commit -m 'test' 命令，尝试提交代码，会发现提交失败，命令行输入如下图。

如上图所示，在提交时检测到代码不合乎 eslint 标准，提交失败了。

如果咱们心愿在检测谬误的同时，主动修复 eslint 语法错误，则须要用到 lint-staged，应用 npm i lint-staged -D 先进行装置，而后在 package.json 中批改 pre-commit 命令，再增加以下内容。

"scripts": {"pre-commit": "lint-staged"},
"lint-staged": {
  "src/**": ["eslint --fix"]
}

接下来，咱们再次运行 git add . 和 git commit -m 'test' 命令，尝试提交代码，输入如下图。

从上图能够看出，在运行 lint-staged 命令后，会通过 eslint --fix 主动将不合乎规格的代码正确格式化。

这样一来，代码提交时的自动检测和格式化代码工作就实现了。

应用脚手架，将配置自动化

手动配置的问题

在实现上述配置后，仿佛曾经功败垂成，马上能够走在标准编码的欢快路线上，然而并没有。

咱们认真梳理一下会发现，咱们须要在某个新我的项目中配置代码标准时，须要进行以下繁琐的步骤。

1. 装置 Eslint。
2. 依据我的项目类型装置对应的 ESLint 规定配置 npm 包。
3. 依据我的项目类型装置相干的插件、解析器等。
4. 依据我的项目类型配置 .eslintrc .prettierrc 文件。
5. 装置代码提交查看 + 主动格式化工具。husky + lint-staged
6. 配置 package.json。
7. 测试及修复问题。

这些繁琐的步骤会消耗大量的工夫，并且可能还会呈现一些谬误须要额定花工夫去排查。这样的流程对于集体来说可能是个比拟好的学习机会，然而对于团队来说的确是个低效的合作形式。

所以，咱们能够借助一些工具来帮忙实现上述工作，这个工具能够依据配置抉择，生成对应的标准配置，并装置能够相互兼容的依赖包。

应用脚手架进行主动配置

咱们先应用 npm i standard-config-cli -g 命令全局装置脚手架工具，而后在对应的目录下运行 jgxl standard 命令。

这里咱们以 vue + typescript 命令为例，抉择的配置如下图。

在初始化实现后，对应的几个配置文件内容如下：

.eslintrc.js

.prettierrc.js

package.json

从下面能够看出，咱们的标准配置会依据所选配置，生成对应的标准配置文件，并且曾经装置了相干版本的依赖。

作为团队成员，不须要关怀这些标准的细枝末节，只须要进行外围业务开发即可。

TIPS：主动修改 性能只能修改局部代码格调标准，对于一些可能产生隐患的代码问题不会主动修改（例如：定义而未应用的变量）。

小结

在代码格调标准的争执上，每个人都有本人的了解，永远没有正确的答案。把工夫用于细枝末节上争执，不如多把关注点聚焦在外围业务上。

而不管怎样争执，总归会抉择一种格调。在这个方面，也须要在集体语义和普适价值上做一个衡量。

所以，抉择一份前端标准规范（如 standard），而后放弃吧。把工夫留下来解决其余有意义的问题！(^____^)/

参考资料：

• Javascript 的 10 个设计缺点
• eslint
• standard
• prettier
• 应用 ESLint+Prettier 来对立前端代码格调
• ESLint 在中大型团队 (美团) 的利用实际
• Why (and how) to use eslint in your project
• Automate Your Coding Standard

最初一件事

如果您曾经看到这里了，心愿您还是点个赞再走吧~

您的点赞是对作者的最大激励，也能够让更多人看到本篇文章！

如果感觉本文对您有帮忙，请帮忙在 github 上点亮 star 激励一下吧！