前端lint规范

1.ESlint

背景

ESLint是一个代码静态分析的检测工具，其可以在代码编写的时候就进行静态分析（而不用在代码运行时候才进行分析），以提前保证代码的一致性和避免错误。可以帮助我们在项目开发中建立统一的团队代码规范，保持一致的代码风格，提高代码的可读性和可维护性。

原理

1. Eslint本质上是通过JS编译器将源代码通过词法分析，转化为token数组，然后经过语法分析，生成AST树语法树。
2. 然后对AST语法树进行遍历，检查每一个节点是否符合语法规范。

如何使用

step1：安装ESlint - npm install eslint -D
step2：生成相应的配置文件：npx eslint --init

module.exports = { 
  "env": { 
    "browser": true, // 要检查的js代码是运行在浏览器端 
    "commonjs": true, // 使用commonjs模块化规范 
    "es2021": true // 对ES2021以前的语法都可以进行检查 
  }, 
  "extends": [ 
    "eslint:recommended", // 继承eslint官方推荐的检查规则 
    "plugin:react/recommended", // 继承react推荐的检查规则   
    "plugin:@typescript-eslint/recommended" //继承typescript推荐的检查规则 
   ], 
   "parser": "@typescript-eslint/parser", // js代码的解析器，eslint默认的代码解析器是espree；由于项目中存在ts代码所以编译指定为专门解析ts代码的解析器 
   "parserOptions": { 
      "ecmaFeatures": {
         "jsx": true // 对jsx语法也进行检查 }, 
         "ecmaVersion": "latest", // 和env中配置的ECMA版本对应 
         "sourceType":"module" // 如果我们在初始化的时候选择了模块化规范是Commonjs 如果要想同时支持ESmodule，那么必须在解析配置这里写上这一句，否则会报错
         }, 
         "plugins": [ "react", "@typescript-eslint" ], 
         "rules": {
             "linebreak-style":"off", // 此条规则的意思是强制使用一致的换行符风格。
             "space-before-blocks":"off", // 该规则将强制块之前的空格的一致性。
             "no-unused-vars":0, // 不允许存在已经声明但是从未使用的变量，关闭该规则
             "no-tabs":"off", //  文件中任何位置不允许出现tab字符，包括代码和注释，将其关闭。
             "quotes":["error","double"], // 引号配置
         } 
 }

step3：Vscode中进行eslint插件配置

首先先将eslint安装到项目中 eslint和selint-plugin-vue以及对应的prettier。安装好之后新建一个eslintrc.js这样一个eslint配置文件（具体的规则配置）， 这里需要注意的是我们也可以通过下载eslint-loader这样在每次代码启动或者打包的时候进行lint校验，但是这就会导致编译阶段的时间过长。因此最好转为我们在写代码的同时就开始帮我们校验，因此在VScode中进行配置是最好的。

写代码的时候ESLint就可以帮助我们检查出来错误，并且对检查出来的代码风格类错误可以进行自动修复。

VSCode中ESLint插件运行的原理：VSCode会默认去项目的根目录下读取.eslintrc.js配置文件，如果有此文件就会按照此文件中的配置信息对代码进行静态检查，如果没有那么会按照VSCode默认的规则来对代码进行检查，并实时将错误报告显示在终端。

step4：.eslintignore
创建一个eslint的忽略文件 .eslintignore

2.代码提交钩子 - husky

2.0 出现背景

我们在终端执行git命令的时候，需要对git命令进行一个管理，按照git命令的先后顺序我，git在相应的命令前后都有对应的git-hooks钩子。我们利用这些钩子就可以做一些自动化规范检测的动作：

• 代码质量上-单元测试检测命令：npm test
• 代码规范上-执行eslint检测命令： npm run lint

// package.json文件
"husky": {
  "hooks": {
    "pre-commit": "npm run lint && npm test"
  }
}
// 然后在 package.json 中添加相应的 lint 和 test 对应的script脚本，可以使用 eslint、prettier、jest 等工具进行代码校验和测试。

2.1 husky执行原理

1. git 内置特定的 执行钩子
我们在终端执行git命令的时候，需要对git命令进行一个管理，按照git命令的先后顺序我，git在相应的命令前后都有对应的git-hooks钩子。一个比较典型的例子：我们在使用git commit -m'msg'做commit提交的时候，git就给这个命令预留了前后四个钩子：pre-commit && commit-msg（提交信息的检查）&& post-commit（提交后钩子）。

问题 如果我们不用husky，向自己配置对应的git-hook走的脚本是否可以？ 答案是可以的，git自己有自己的hooks钩子脚本，我们在.husky文件夹下就可以看见各种git-hooks对应的脚本文件，我们可以直接在自己的电脑中写，就可以执行对应的git脚本。但是问题在于我们在团队内开发的时候，不可能将你的电脑的git钩子脚本一个一个复制到别人的电脑中。因此这种方法不适合团队管理。

2. husky针对.git文件夹做增量hook
因为git会执行内部的.git文件夹下的钩子文件，而husky配置就是在这个文件外独立创建额外的hooks文件，然后一起执行hooks脚本，这样就不会覆盖原本的hooks文件。

3.文件过滤工具 - lint-staged

3.1 什么是lint-staged？

我们可以认为lint-staged是一个过滤出git代码暂存区文件的工具，即文件过滤器。让我们实现在开发时候使用lint-staged过滤出暂存区的代码，然后将这部分代码再交给lint校验。
但是如果你是git add -A的话，那么这种校验相当于失效了，所以建议使用 git add .而不是git add -A。

git的暂存区

我们知道git init之后，会形成三个主要区域：工作区（Working Directory）、暂存区（Staging Area）、版本库（Repository）。

使用 Git 的工作流程是：先将文件放入工作目录中，然后使用 git add <文件名>命令将该文件添加到暂存区，接着使用 git commit提交到版本库中 。
暂存区的定义和操作
我们使用git add <具体文件名> 命令，这个时候就是将这些add指定添加的文件放到暂存区中
如果我们使用git add ., 那么就是将当前目录下所有 修改的 文件放入到暂存区
如果我们使用git add -A, 那么就是将当前目录下 所有文件 放入到暂存区
参考文献：segmentfault.com/a/119000004…

3.2 lint-staegd配置

step-1. npm install --save-dev lint-staged husky
step-2.配置pacakage.json文件
// pacakage.json
{ 
  "husky": { 
     "hooks": { 
        "pre-commit": "lint-staged" 
        // 在执行git commit命令时候，会在commit之前先出发pre-commit钩子，即执行lint-staged命令
      } 
   }, 
   "lint-staged": { // 对lint-staged命令的具体操作进行配置：
       // 配置1：对本次被commited中的所有`.js`文件，执行`eslint --fix`命令和`git add`,命令，
       // 前者eslint --fix的目的是格式化，后者是对格式化之后的代码重新提交。
       "*.js": ["eslint --fix", "git add"] 

    } 
}

问题： 但是对所有暂存区代码进行lint，但是如果我们使用git add -A的话，相当于又对所有文件进行lint了，那么就会更改之前的历史代码格式，导致无法溯源，因此我们需要进一步，只对更改的代码进行lint，这个时候就需要eslint-plugin-diff了。

4.eslint-plugin-diff 插件

为了解决上述每次在缓存区中额外过滤出更改的文件，使用了eslint-plugin-diff插件

npm install --save-dev eslint eslint-plugin-diff

在对应的eslint配置文件-.eslintrc.js，使用extends共享字段进行配置，这样就可以将eslint-plugin-diff的eslint配置共享到我们项目中了。

eslint配置中的共享配置字段 - extends
项目中的.eslintrc（eslint配置文件）中的rules就是eslint配置中的规则(rule)的集合，就是来告诉eslint如何检查代码的。但是eslint中规则很多，我们不可能一个个配置，或者及时拷贝过来也很麻烦，那么我们就可以使用extends共享别人的配置：例如 ：

module.exports = {
    "extends": "standard",
    // "extends": "eslint-config-standard", 
    // 跟上面一样，只是换了个写法 当共享的配置文件命名遵循了```eslint-config-*```的命名规范时，可以省略```eslint-config-```
}

项目中配置
对应到我们项目使用中就是：（这里需要注意的是，我们只需要本地执行而不希望在远端CI的时候执行，因此可以设置只在git commit时候执行eslint-diff操作）

{
  "extends": ["plugin:diff/staged"]
}

场景题
1.在每次git commit提交的时候只对更改的文件做lint校验，不用对暂存的所有文件校验。以避免改了一行代码，所有文件都lint更改，导致不必要的错误 & 不好溯源。

解决方案：husky、lint-staged、eslint-plugin-diff

参考文献：www.null123.com/question/de…

面试题

• 怎么启动eslint

step1：安装ESlint - npm install eslint -D
step2：生成相应的配置文件：npx eslint --init ，生成eslintrc配置文件
step3：启动分为两种-在项目运行时候检查，即通过命令：npx eslint就能检查目录下所有文件。另一种是通过vscode配置，在代码编写的时候就进行检查，而不用等到项目启动时候。
step4：确定eslint校验文件的范围：eslint src（指定目录），然后配置eslint-ingore配置剔除掉不用校验的文件。
或者通过--ext配置，去只校验指定后缀名的文件 eslint --ext .js,.vue / eslint --ext .js,.vue src (只校验指定目录(src)中 指定后缀名(.js,.vue)的文件)

• 怎么配置eslint规则

eslint主要的配置项有： root parserOptions // 之前bebal解析器 env 环境配置 extends 项目共享规则 rules 自定义规则配置

• 校验出现的问题必须手动修改吗？能否自动修改

eslint --ext .js,.vue src --fix
注：--fix 参数了解一下 这个选项不会修复所有的错误哈，基本的格式错误（换行啊，缺少空格啊等都会修复）

• 使用那一套eslint
• 常见的eslint配置是什么？

rules: {
   'arrow-spacing': [2, { 
      'before': true,
      'after': true
    }], // 禁止或强制在单行代码块中使用空格
    'block-spacing': [2, 'always'], // 空格配置：单行代码块中使用空格
    'brace-style': [2, '1tbs', { 'allowSingleLine': true }], // 缩进配置
}