JS代码风格利器——Eslint_eslint.js

ESLint 是一个开源的 JavaScript 代码检查工具，由 Nicholas C. Zakas 于 2013 年 6 月
创建。代码检查是一种静态的分析，常用于寻找有问题的模式或者代码，并且不依赖于具体
的编码风格。对大多数编程语言来说都会有代码检查，一般来说编译程序会内置检查工具。
然而JavaScript 是一个动态的弱类型语言，并没有内置检查工具，因此在开发中比较容易出错。为了寻找 JavaScript 代码错误通常需要在执行过程中不断调试。像 ESLint 这样的检查工具可以让程序员在编码的过程中发现问题而不是在执行的过程中。
ESLint 的初衷是为了让程序员可以创建自己的检测规则。ESLint 的所有规则都被设计成可插入的。ESLint 的默认规则与其他的插件并没有什么区别，规则本身和测试可以依赖于同样的模式。为了便于人们使用，ESLint 内置了一些规则，当然，你可以在使用过程中自定义规则。
ESLint 使用 Node.js 编写，这样既可以有一个快速的运行环境的同时也便于安装。

Lint含义

如果你写自己的项目怎么折腾都没关系，但是在公司中老板希望每个人写出的代码都要符合一个统一的规则，这样别人看源码就能够看得懂，因为源码是符合统一的编码规范制定的。
那么问题来了，总不能每个人写的代码老板都要一行行代码去检查吧，这是一件很蠢的事情。凡是重复性的工作，都应该被制作成工具来节约成本。这个工具应该做两件事情：

• 提供编码规范；
• 提供自动检验代码的程序，并打印检验结果：告诉你哪一个文件哪一行代码不符合哪一条编码规范，方便你去修改代码。

Lint 是检验代码格式工具的一个统称，具体的工具有 Jslint 、 Eslint 等等

使用Eslint

1. 本地安装

npm i eslint --save-dev

2. 设置package.json文件

“scripts”: {
“lint”: “eslint ./src”,
“lint:create”: “eslint --init”
}

3. 执行下面命令生成配置文件：.eslintrc.js

npm run lint:create

4. 检查js文件

npx eslint 目录名

• .eslintrc.js文件案例如下

module.exports = {
    "env": {
        "browser": true,
        "es2021": true
    },
    "extends": "eslint:recommended",
    "overrides": [
    ],
    "parserOptions": {
        "ecmaVersion": "latest"
    },
    "rules": {//不是没有制定规则，而是有了默认的规则
    }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
'
运行
运行

• package.json文件案例如下

{
  "name": "react_staging",
  "version": "0.1.0",
  "private": true,
  "dependencies": {
    "@testing-library/jest-dom": "^5.16.5",
    "@testing-library/react": "^13.4.0",
    "@testing-library/user-event": "^13.5.0",
    "react": "^18.2.0",
    "react-dom": "^18.2.0",
    "react-scripts": "5.0.1",
    "web-vitals": "^2.1.4"
  },
  "scripts": {
    "start": "react-scripts start",
    "build": "react-scripts build",
    "test": "react-scripts test",
    "eject": "react-scripts eject",
    "lint": "eslint ./src",
    "lint:create": "eslint --init"
  },
  "eslintConfig": {
    "extends": [
      "react-app",
      "react-app/jest"
    ]
  },
  "browserslist": {
    "production": [
      ">0.2%",
      "not dead",
      "not op_mini all"
    ],
    "development": [
      "last 1 chrome version",
      "last 1 firefox version",
      "last 1 safari version"
    ]
  },
  "devDependencies": {
    "eslint": "^8.35.0",
    "eslint-plugin-react": "^7.32.2"
  }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

跳过lint校验——两种方式

const apple = "apple"; // eslint-disable-line
const balana = "balana"; // eslint-disable-line
 
/* eslint-disable */
   alert('foo');
/* eslint-enable */
1
2
3
4
5
6

EditorConfig

在团队开发中，统一的代码格式是必要的。但是不同开发人员使用的编辑工具可能不同，这样就造成代码的不统一。
目前为止，还是有很多人陷入在 tabs vs spaces 之类的争论中。不是每个人都在严格要求自己的代码规范和风格，对于多人协作的项目这容易出现问题。毕竟每个人所用的 IDE 和编辑器都可能不同。
EditorConfig 帮助开发人员定义和维护不同编辑器之间一致的编码风格。
EditorConfig 项目由定义编码样式的文件格式和一组文本编辑器插件组成，这些插件使编辑器能够读取文件格式并坚持已定义的样式。编辑器配置文件易于阅读，并且可以很好地与版本控制系统一起工作
你只需配置一个 .editorconfig 文件，在其中设置好要遵守的代码规范，放在项目的根目录下，就能够在几乎所有的主流 IDE 和编辑器中复用了，可以将 .editorconfig 文件也提交到版本控制系统中，就不需要针对不同 IDE 和编辑器再单独进行设置了。

*                匹配除/之外的任意字符串
**               匹配任意字符串
?                匹配任意单个字符
[name]           匹配name中的任意一个单一字符
[!name]          匹配不存在name中的任意一个单一字符
{s1,s2,s3}       匹配给定的字符串中的任意一个(用逗号分隔) 
{num1..num2}   　匹配num1到num2之间的任意一个整数, 这里的num1和num2可以为正整数也可以为负整数
1
2
3
4
5
6
7

• .editorconfig文件案例如下

# 通常建议项目最顶层的配置文件设置该值
root = true

#表示以 Unix风格的换行符结尾
[*]
end_of_line =1f
insert_final_newline = true

[*.{js,py}]
charset = utf-8

# 四格缩进
[*.py]
indent_style = space
indent_size = 4

# 设置缩进类型为tab
[Makefile]
indent_style = tab

#覆盖lib目录下的所有js文件的缩进宽度为2空格
[src/**.js]
indent_style = space
indent_size = 2

#精确匹配package.json
[{package.json}]
indent_style = space
indent_size = 4
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

官方文档

相关的规则，我们可以参考官方文档，而不是去死记硬背，因为背不下来。。。
https://eslint.org/