目录
导读
linter 原理
一、有哪些常见的 linter
├── ESLint
└── Stylelint
└── commitlint
└── TSLint
└── Prettier
二、配置ESLint
三、配置 Stylelint
四、配置 commitlint
五、接入 husky 和 lint-staged 在 git hooks 里拦截检测
六、配置 Prettier
导读
lint 的诞生来源于C语言中静态代码分析工具，随着各路语言杀出重围，lint 家族也随之壮大，现在 lint 通常用语标记任何代码编写中可疑或错误使用的工具，或者表示对源代码进行静态检查的行为，拥有这方面能力的工具都被称为 linter。
lint 的使用能促进我们在代码提交之前发现代码的错误，我们能在合适的时间触发lint，检测代码错误。lint 规则的统一，能让团队代码风格统一。
linters 原理
为了更好的理解 linter，简单的梳理一下它们的工作流程：
一、有哪些常见的linter？
-
ESLint
ESLint 是一个开源的 JavaScript 代码检查工具，使用 Node.js 编写。它规范并校验 ECMAScript/JavaScript code 的编写，由于用户量庞大它推出了一套符合大部分用户编码规范的内置的规则，但它本身并不推荐任何编码风格，规则是自由的，ESLint 的所有规则都被设计成可插入的，用户可以创建自己的检测规则，配合 parser 和 plugins，ESLint 也是 vue、react、typescript类型的代码检测工具的首选。
-
Stylelint
它是对齐样式规范化的工具，能兼容多种格式的 css 代码、定义样式的顺序、解析各种预处理器，使用它统一样式代码风格规范。
-
commitlint
引用官方的话术，commitlint 检查你的提交消息是否符合常规的提交格式。规范的 commit 信息可以清晰地看清楚每次提交的行为。
TSLint
tslint 已经不再维护了，推荐使用 ESLintPrettier
Prettier是一个代码格式化工具，它支持HTML/CSS、Less、SCSS/JavaScript/TypeScript/Vue/JSX/JSON/Markdown等类型文件，基本涵盖前端项目相关的所有文件类型的 format。
内置了丰富的规则，少部分支持自定义配置，所以想在有 Linters 的基础上想接入 Prettier 做代码的 format，会和其他 Linters 的规则产生冲突，需要优先使用 Prettier 的规则。
二、配置ESLint：
安装
npm i -D eslint，这会在./node_modules/.bin目录下创建 eslint.js ，这是 eslint 执行的入口，感兴趣的同学可以看看源码。
配置
配置的几种方式：
- 1、在项目根目录创建名为
.eslintrc.js的文件，配置的详细解读写到下面注释里了：
// .eslintrc.js
module.exports = {
root: true, // 停止在父级目录中寻找 .eslintrc.* | package.json 文件里的 eslintConfig
parser: 'vue-eslint-parser',// 指定代码解析器，通常配合 plugin 对 js 以外类型的代码做检测，将将其他类型代码转换为与 ESTree(默认解析器) 兼容的形式兼容 eslint
parserOptions: { // 解析器选项。帮助 ESLint 确定什么是解析错误，所有语言选项默认都是 false
ecmaVersion: 2020, // ecma版本：支持 ES 的语法，默认支持 ECMAScript 3、5 语法，可以选值有：6, 7, 8, 9, 10, 11, 12，也可以写对应的年份
sourceType: 'module', // script (默认) | module（如果你的代码是 ECMAScript 模块)
ecmaFeatures: { // 想使用的额外的语言特性
// globalReturn - 允许在全局作用域下使用 return 语句
// impliedStrict - 启用全局 strict mode (如果 ecmaVersion 是 5 或更高)
// jsx - 启用 JSX
// experimentalObjectRestSpread - 启用对实验性的 object rest/spread properties //的支持。
},
env: { // 在哪些环境中运行，每个环境都会带来一组预定义的全局变量。
/**
* browser、node、shared-node-browser、commonjs、esxxx、worker、amd、mocha、jasmine、jest、phantomjs
* protractor、qunit、jquery、prototypejs、shelljs、meteor、mongo、applescript、nashorn、serviceworker
* atomtest、embertest、webextensions、greasemonkey
*/
browser: true, // 浏览器全局变量
node: true, // Node.js 全局变量和 Node.js 作用域
es6: true // 启用 ES6 语法支持 及 新的 ES6 全局变量
},
globals: { // 定义全局变量。
/**
* 访问当前源文件内未定义的变量时，no-undef 规则将发出警告。
* 如果你想在一个源文件里使用全局变量，推荐你在 ESLint 中定义这些全局变量，这样 ESLint 就不会发出警告了
**/
var1: 'writable', // writable: 允许被覆盖
var2: 'readonly' // readonly: 只读
var3: 'off' // off: 禁用
},
extends: [ // 一个配置文件可以从基础配置中继承已启用的规则，简单理解就是用别人写好的.eslintrc.js配置
'eslint:recommended', // 官方报告规则页面上标记为 √ 的规则。推荐的子集会在 ESLint 的主要版本上更改。
// 'eslint:all', 表示引入当前版本 eslint 的所有核心规则
],
plugins: [ // 接入第三方/自定义的插件, 需要先安装npm插件包
/**
* 为了补充 eslint 内置规则里缺失的能力，新增一些检查规则
* 常用的有 @typescript-eslint/eslint-plugin、省略eslint-plugin-前缀: react、vue、node、prettier、promise
* 加载插件之后就能在 rules 里配置插件的规则: plugin/rule: 0、1、2
**/
],
rules: { // 匹配规则, 官方分类整理好的规则https://eslint.org/docs/rules/
/**
* 对代码进行各种限定，统一风格
* ESLint带有大量内置规则, 必须将规则ID设置为以下值之一
* 'off' 或 0 -关闭规则
* 'warn' 或 1 -将规则作为警告（不会影响退出代码）
* 'error' 或 2 -将规则作为错误打开（触发时退出代码为1）
*/
}
}
}
- 2、在
package.json下创建eslintConfig属性进行配置，配置项和.eslintrc一样不再赘述：
"eslintConfig": {
// ...
}
如果在同一目录中找到一个 .eslintrc 和 package.json 文件，.eslintrc 则将具有优先权，并且 package.json 将不使用该文件。
默认情况下，ESLint 将在所有父文件夹中寻找配置文件，直到根目录为止。如果你不想这么做可以设置配置'root': true，EsLint 将停止在父文件夹中寻找配置文件。
- 3、在单个文件里面中添加配置（不到迫不得已，不推荐）：
/* eslint no-multi-spaces: "error" */
执行
按需写好配置文件，验证一下 eslint 是否正常工作，在根目录下创建文件 eslintTest.js：
// eslintTest.js
console.log(a);
通过 yarn、npx 这类型工具执行 ./node_modules/.bin 下的 eslint 脚本：
npx eslint ./eslintTest.js
根据错误提醒找到问题代码，一些简单的样式错误可以配合规则里的修复方案和
--fix自动修复：
// eslintTest.js
let a; // 变量前面多加点空格
console.log(a);
// .eslintrc.js
module.exports = {
//其他配置...
rules: {
'no-multi-spaces': 'error'
}
}
执行npx eslint --fix ./eslintTest.js之后，问题代码被修复：
// eslintTest.js
let a;
console.log(a);
自动化设置
如果觉得每次编写完代码都要执行 eslint 有些麻烦可以配合 ide 的插件在编码过程自动检测并给出提醒
以 vscode 为例：
- 安装插件 eslint
- 在 ide 右下角开启 eslint 插件，ide 就会有错误提示：
留意错误提醒，可以手动修改，也可以配置文件保存的时候自动修复(需要手动触发保存)
三、配置 Stylelint
安装
- 安装 Stylelint 和 Stylelint 推荐的规范 stylelint-config-standard
npm i -D stylelint stylelint-config-standard
生成配置文件
- 用推荐的规范生成配置文件
echo '{"extends": "stylelint-config-standard"}' > .stylelintrc.json
也可以根据团队的风格自定义配置，在配置文件里增加规则，配置rules 属性，stylelint 提供超过 170 个内置规则，例如：
// example
{
//其他配置...
"rules": {
"color-no-invalid-hex": true
}
}
规则的值需满足以下格式之一：
- null (关闭规则)
- a single value (主要选项，value的类型可以是boolean、string、array......看规则的具体定义)
- [primary option, secondary options] ([主要选项, 规则的辅助配置])
// example
{
//其他配置...
"rules": {
"indentation": [
2,
{
"except": ["block"], // 接收一组规则命名，过滤的时候取反
"message": "Please use 2 spaces for indentation.", // message：违反规则时，提示自定义消息
"severity": "warning" // severity：违反规则发出的错误级别：error (默认)、warning
}
]
}
}
执行
执行 stylelint 发现潜在的错误和样式问题：
npx stylelint <文件路径>
npx stylelint "**/*.css" // 检测所有 CSS
加上 --fix 自动修复问题：
npx stylelint <文件路径> --fix
自动化设置
配合 ide 自动化检测并修复，以 vscode为例：
-
安装 stylelint 插件
在 settings.json里添加配置
"editor.codeActionsOnSave": {
"source.fixAll.eslint": true,
"source.fixAll.stylelint": true,
}
// 也可以简写成 ⬇️
"editor.codeActionsOnSave": {
"source.fixAll": true,
}
配置完成就能在手动保存代码的时候自动修复样式问题
四、配置 commitlint
安装
- 安装 commitlint 和 commitlint 推荐的提交规范 config-conventional
npm install -g @commitlint/cli @commitlint/config-conventional
生成配置文件
- 用推荐的规范生成配置文件
echo "module.exports = {extends: ['@commitlint/config-conventional']}" > commitlint.config.js
提交规范
[optional scope]:
[optional body]
[optional footer(s)]
| 元素 | 含义 |
|---|---|
| type | 本次提交的改动类型，例如 @commitlint/config-conventional 中推荐的 fix、feat、build、chore、 ci、docs、style、refactor、perf、test、revert |
| optional scope | (可选) 修改的范围，例如某个文件、某个模块、某个目录下等等 |
| description | 本次提交的概括，短而精 |
| optional body | (可选) 本次提交的详细说明 |
| optional footer(s) | (可选) 脚注 |
例子： 'fix(login): 修复登陆流程的bug'、feat(xx): 在xx模块增加xxx功能
常用的type：
| type | 含义 |
|---|---|
| fix | 修复 Bug |
| feat | 添加新特性或功能 |
| chore | 跟主要业务无关的构建/工程依赖/工具等功能改动 |
| docs | 更新文档 |
| style | 代码样式调整 |
| refactor | 代码结构优化或重构 |
| perf | 优化代码性能 |
| test | 新增或修改测试代码 |
测试
打开终端，输入
echo 'testType: test texttest' | commitlint
会提示如下错误：
⧗ input: testType: test texttest
✖ type must be lower-case [type-case]
✖ type must be one of [build, chore, ci, docs, feat, fix, perf, refactor, revert, style, test] [type-enum]
✖ found 2 problems, 0 warnings
ⓘ Get help: https://github.com/conventional-changelog/commitlint/#what-is-commitlint
通常 @commitlint/config-conventional 的配置也够用了，如果想定义自己的规范也可以到 官方配置例子、Rules 里参照配置合适的规则
五、接入 husky 和 lint-staged 在 git hooks 里拦截检测
配合上面配置好的 eslint``、stylelint、commitlint，我们可以在 git hooks 里完成对代码和提交信息的校验
Git Hooks 是 git 操作不同阶段的钩子(如 commit、push...)，钩子都被存储在 Git 目录下的 hooks 子目录中。 也即绝大部分项目中的
.git/hooks。 当你用git init初始化一个新版本库时，Git 默认会在这个目录中放置一些示例脚本。常用的钩子：
| 常用钩子 | 说明 |
|---|---|
pre-commit |
在键入提交信息前运行，通常在这里进行单元测试，以及核查代码。 |
commit-msg |
接收提交信息，即存有当前提交信息的临时文件的路径，在这可以验证项目状态或提交信息。 |
post-commit |
在整个提交过程完成后运行，在这可以发送一些通知，还能自动重新部署项目，感兴趣的同学可以思考一下 |
-
husky是什么？
husky 是一个帮助我们添加 hook 的工具，会帮我们在 .git/ 目录下增加钩子，我们只要编写好钩子里的任务便大功告成。心细的同学会发现就算在钩子里面增加一层代码检测拦截但整个项目文件这么多也太费时了，要是能够只检测改动过的文件就好了。
当然，为了追求高效我们还要接入 lint-staged, lint-staged 是一个在git暂存文件上运行 linters 的工具，配合 husky 只检验改动过的文件。
- 安装
npm i -D husky lint-staged
- 配置
1、在 package.json 里添加 prepare 配置：
"scripts": {
//其他配置...
"prepare": "husky install"
},
husky install 将会在 npm install 安装完项目以来后会触发，husky 会创建.husky/目录，并指定该目录为 git hooks 的入口
2、执行 prepare：
正常情况下，项目初始化的时候会执行 npm install 会触发 prepare。当前是第一次接入，我们手动执行一下：
npm run prepare
发现创建好了 .husky：
3、在根目录，创建一个 .lintstagedrc 配置文件，写入配置：
echo '{
"*.{js,vue}": ["eslint --fix", "git add"],
"*.{html,vue,css,scss,sass,less}": ["stylelint --fix", "git add"]
}' > .lintstagedrc
将匹配所有改动过以 .js、.vue文件执行 eslint检测并修复代码问题，匹配所有改动过以 .html、.vue、. css、. scss、. sass、. less文件执行 stylelint检测并修复代码问题。
4、增加 pre-commit、commit-msg 钩子：
npx husky add .husky/pre-commit 'npx lint-staged'
npx husky add .husky/commit-msg 'npx --no-install commitlint --edit $1'
5、验证一下：
新建测试文件，测试拦截情况：
如果遇到 eslint 或者 stylelint 自动修复不了的问题会报错❌
到这里已经顺利在 pre-commit、commit-msg 钩子里接入了代码检测和提交信息的过滤
六、配置 Prettier
1、安装
npm install --save-dev --save-exact prettier
2、创建配置文件，可以到 官网规则里了解按需写到配置文件里
echo {} > .prettierrc.json
3、(可选) 创建.prettierignore文件，让 Prettier CLI 和编辑器知道哪些文件不格式化。
// .prettierignore
build
4、格式化文件
npx prettier --write .
以上是 Prettier 最简洁的使用方式
集成到 Linters
Prettier 官方推出了配置和插件供我们与 Linters 集成：
- ESLint:
eslint-config-prettier：关闭所有不必要的规则或可能与 Prettier 冲突的规则
eslint-plugin-prettier：将 Prettier 作为 ESLint 规范来使用
集成到 ESLint：
1、安装
npm install --save-dev eslint-plugin-prettier eslint-config-prettier
npm install --save-dev --save-exact prettier // 如果已经安装了prettier可忽略
2、在 .eslintrc.* 增加配置
// eslintrc.js
{
plugins: [
//其他配置...
"prettier"
],
extends: [
//其他配置...
"plugin:prettier/recommended"
]
rules: {
//其他配置...
"prettier/prettier": "error"
}
}
- stylelint：
stylelint-config-prettier：关闭所有不必要的或可能与Prettier冲突的规则
stylelint-prettier：将 Prettier 作为 Stylelint 规范来使用
集成到 stylelint：
1、安装
npm install --save-dev stylelint-config-prettier stylelint-prettier
npm install --save-dev --save-exact prettier // 如果已经安装了prettier可忽略
2、在 . stylelintrc.* 增加配置
// stylelintrc.json
{
"plugins": [
//其他配置...
"stylelint-prettier"
],
"extends"：[
//其他配置...
"stylelint-config-prettier" // 确保将其放在最后，这样它将覆盖其他配置
],
"rules": {
//其他配置...
"prettier/prettier": true
}
}
stylelint-config-prettier 附带了一个工具，可以检查配置是否包含与Prettier冲突的规则，为了执行工具，首先将脚本添加到package.json：
{
"scripts": {
"stylelint-check": "stylelint-config-prettier-check"
}
}
然后执行 npm run stylelint-check
3、husky 接入 Prettier
如果已经配置过 husky，会有如下配置文件，如果没配置翻到上面第五点
// pre-commit
. "$(dirname "$0")/_/husky.sh"
npx lint-staged
在 lintstage 配置文件里增加配置：
// .lintstagedrc
{
"*.{js,vue}": ["eslint --fix", "git add"],
"*.{html,vue,css,scss,sass,less}": ["stylelint --fix", "git add"],
"*.{js,html,vue,css,scss,sass,less}": ["prettier --write", "git add"],
}
经过上面的配置，在提交代码的时候 Prettier 就会帮我们 format 一下再提交啦
linters 的介绍和使用就到这里啦，感谢阅读
参考 ESLint官方文档、 commitlint官方文档、stylelint官方文档、Prettier