code

前言

多人开发通常会有代码风格不统一的情况，使用不同的编译器等，造成项目不同代码文件风格不一致，为了解决这个问题，出现了一些能自动格式化的工具，如prettier等。

常见的语法规则和代码风格检查工具有ESLint, 代码风格及语法规则和格式化工具Standard, 代码格式化工具Prettier

1. ESLint

可组装的JavaScript/JSX检查工具，它是一个由Nicholas C. Zakas于2013年开源的一个Pluggable Linter for JavaScript/JSX.

其运行是根据默认规则如 ECMAScript 5 语法检测和用户自定义规则进行语法检测，可通过自定义规则及插件添加其支持的其他类型的JS，如React.js, Vue.js等。

官网对其的描述:

ESlint 被设计为完全可配置的，这意味着你可以关闭每一个规则而只运行基本语法验证，或混合和匹配 ESLint 默认绑定的规则和你的自定义规则，以让 ESLint 更适合你的项目。

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

使用ESLint的流程：

1. 首先在项目中或全局通过npm i -g eslint 安装npm包。
2. 在项目根目录或全局(window默认为C盘用户根目录)建立配置文件, 以.eslintrc开头，比如.eslintrc.json或.eslintrc.js等。
3. 通过命令行使用 eslint filename将会对文件进行检测，支持正则表达式，对于发现的错误可以使用eslint --fix进行部分修复。
4. 与IDE的集成，通常我们都是直接通过IDE,如VSCode结合插件进行代码语法及风格实时检测。
   以VSCode为例，需要在Extensions中安装ESLint插件，可以通过VSCode的setting.json进行ESLint规则配置，也可以在setting.json中指定要使用的配置文件.eslintrc.*地址。

配置详解：

有两种主要的方式来配置 ESLint：

1. Configuration Comments - 使用 JavaScript 注释把配置信息直接嵌入到一个代码源文件中。
2. Configuration Files - 使用 JavaScript、JSON 或者 YAML 文件为整个目录（处理你的主目录）和它的子目录指定配置信息。可以配置一个独立的 .eslintrc.* 文件，或者直接在 package.json 文件里的 eslintConfig 字段指定配置，ESLint 会查找和自动读取它们，再者，你可以在命令行运行时指定一个任意的配置文件。

如果你在你的主目录（通常 ~/）有一个配置文件，ESLint 只有在无法找到其他配置文件时才使用它。

配置信息：

• Environments - 指定脚本的运行环境。每种环境都有一组特定的预定义全局变量。
• Globals - 脚本在执行期间访问的额外的全局变量。
• Parser - 指定解析器，如使用babel-eslint对新的JS语法进行支持。解析器需要通过npm进行安装。
• Plugins - 配置第三方插件，如react, vue，可以省略eslint-plugin前缀

{
    "plugins": [
        "vue"
    ]
}

注意：由于 Node.js 的 require 函数的行为，全局安装的 ESLint 实例只能使用全局安装的 ESLint 插件，本地安装的版本，只能用 本地安装 的插件。不支持混合本地和全局插件。

• Rules - 启用的规则及其各自的错误级别，可添加自定义规则。

ESLint 附带有大量的规则。你可以使用注释或配置文件修改你项目中要使用的规则。

要改变一个规则设置，你必须将规则 ID 设置为下列值之一：

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

对不想让eslint进行规则检测的js代码可以用以下方式进行注释

/* eslint-disable no-alert, no-console  */

alert('foo');

/* eslint-enable no-alert, no-console  */

alert('foo'); // eslint-disable-line

// eslint-disable-next-line
alert('foo');

/* eslint-disable-next-line */
alert('foo');

alert('foo'); /* eslint-disable-line */

如果在整个文件范围内禁止规则出现警告，将 /* eslint-disable */ 块注释放在文件顶部：

所有这些选项让你可以细粒度地控制 ESLint 如何对待你的代码。

• Extends -递归扩展规则

一个配置文件可以被基础配置中的已启用的规则继承。
extends 属性值可以是：

1. 在配置中指定的一个字符串
2. 字符串数组：每个配置继承它前面的配置
   ESLint 递归地进行扩展配置，所以一个基础的配置也可以有一个 extends 属性。

此外eslint也可以扩展插件中的配置：
extends 属性值可以由以下组成：

• plugin:
• 包名 (省略了前缀，比如，react)
• /
• 配置名称 (比如 recommended)

{
    "plugins": [
        "react"
    ],
    "extends": [
        "eslint:recommended",
        "plugin:react/recommended"
    ],
    "rules": {
       "no-set-state": "off"
    }

2. Standard

主要用于统一JavaScript代码风格，集成常见配置，无须编写配置文件，只要全局安装或局部安装后通过CLI进行代码检查及自动修复。

以下是官方的介绍：

无须配置。 史上最便捷的统一代码风格的方式，轻松拥有。
自动代码格式化。 只需运行 standard --fix 从此和脏乱差的代码说再见。
提前发现风格及程序问题。 减少代码审查过程中反反复复的修改过程，节约时间。
无须犹豫。再也不用维护 .eslintrc, .jshintrc, or .jscsrc 。开箱即用。

Standard规则检查细则

• 使用两个空格 – 进行缩进

• 字符串使用单引号 – 需要转义的地方除外

• 不再有冗余的变量 – 这是导致 大量 bug 的源头!

• 无分号 – 这没什么不好。不骗你！

• 行首不要以 (, [, or ``` 开头

• 关键字后加空格 if (condition) { ... }

• 函数名后加空格 function name (arg) { ... }

• 坚持使用全等 === 摒弃 == 一但在需要检查 null || undefined 时可以使用 obj == null。

• 处理 Node.js 中错误回调传递进来的 err 参数。

• 使用浏览器全局变量时加上 window 前缀

• 查看更多

Code Linter.png

此外也可集成到VSCode等IDE中，安装standard插件，配置eslint使用standard的代码风格检查规则。

eslint类似一个平台，用于检测和报告信息，而检测的标准规则都是可以自定义的。Standard则包含javascript standard代码风格规则及自动格式化功能，对ESLint扩展，其也可以进行配置，使用eslint-plugin, 如在package.json中

{
  "standard": {
    "parser": "typescript-eslint-parser",
    "plugins": [ "typescript" ]
  }
}

3. Prettier

Prettier仅仅是代码格式化工具，它会移除所有你的代码风格，然后根据它的编码风格如换行标准，最大长度等，从0开始打印出新的，其不仅支持JS，还支持HTML/CSS。

• JavaScript, including ES2017
• JSX
• Angular
• Vue
• Flow
• TypeScript
• CSS, Less, and SCSS
• HTML
• JSON
• GraphQL
• Markdown, including GFM and MDX
• YAML

其仅仅专注于代码格式化，对代码质量检测规则不做保证和检测，以下是官方的说明

How does it compare to ESLint/TSLint/stylelint, etc.?

Linters have two categories of rules:

Formatting rules: eg: max-len, no-mixed-spaces-and-tabs, keyword-spacing, comma-style...

Prettier alleviates the need for this whole category of rules! Prettier is going to reprint the entire program from scratch in a consistent way, so it's not possible for the programmer to make a mistake there anymore :)

Code-quality rules: eg no-unused-vars, no-extra-bind, no-implicit-globals, prefer-promise-reject-errors...

Prettier does nothing to help with those kind of rules. They are also the most important ones provided by linters as they are likely to catch real bugs with your code!

Prettier配置主要是缩进，换行，分号，单引号等信息，可以在其以下配置文件中进行配置。

1. prettierrc file, written in YAML or JSON, with optional extensions: .yaml/.yml/.json.
2. prettierrc.toml file, written in TOML (the .toml extension is required).
3. prettier.config.js or .prettierrc.js file that exports an object.
4. "prettier" key in your package.json file.

Prettier可以与ESLint一起使用，只需安装eslint-plugin-prettier，对Vue的SFC支持，仅需在.eslintrc.*的extends中添加 "plugin:prettier/recommended",
可参考

module.exports = {
  "root": true,
  "extends": [
    "plugin:vue/essential",
    "plugin:prettier/recommended",
    "eslint:recommended"
  ],
}
//https://alligator.io/vuejs/vue-eslint-prettier/
//https://www.futurehosting.com/blog/prettier-vs-eslint-whats-the-difference/