代码规范如何约束？
对于目前的企业级项目，软件开发需要多人协同，不同开发者具有不同的编码习惯和喜好，不同的喜好增加项目维护成本，每个项目或者团队需要明确统一的标准。
eslint
eslint最为主流的 JavaScript Lint 工具监测 JS 代码质量，很容易统一开发者的编码风格，可以帮助开发者提升编码能力。
-
完全的可插拔，一切行为都通过配置产生。
-
任意rule之间都是独立的。
原理： 先通过解析器将javascript代码解析成抽象语法树，再调用规则对AST进行检查，从而实现对代码的检查。
在使用之前，我们需要通过脚手架命令创建eslint的配置文件。
eslint --init
eslint常见配置介绍
-
env 标记代码当前的运行环境。预置当前环境全局变量的集合。
-
extends 继承自一些已经设置好的配置，例如vue,react都已经设置好对应的配置，在其中使用只需要继承即可。
-
parser eslint使用哪种语法解析器。
espree (默认)、esprima、@babel/eslint-parser、@typescript-eslint/parser, 一般不需要指定。 -
parserOption 语法解析器的相关配置，parser会接收这些参数，并影响其解析代码的行为（只是检测语法，对于该语法是否可用，那是env需要做的事情）。
-
rules 每个校验规则的开启或者关闭。eslint无默认开启的规则。但提供了推荐开启的规则
eslint:recommended，我们可以继承它。这里可以看开启了哪些规则。
extends: [
'eslint:recommended'
],
-
plugins 对一系列
rules, env, globals, processors等配置的封装，往往用于特定类型文件的代码检查，例如.md文件。 -
globals 列出可用的全局对象，不做检测。他表示env之外的需要额外指定的全局变量。有三个值
writeable可写、readonly只读、off不支持。
module.exports = {
// 定义js执行环境，主要是生成一个当前环境的全局变量集合
env: {
browser: false,
es2020: true
},
// 继承自一些已经设置好的配置
extends: [
'standard',
'eslint:recommended'
],
// 例如ts就需要配置语法解析器来解析特有的语法
// parser: "",
// 语法解析器的相关配置（只是检测语法，对于该语法是否可用，那是env需要做的事情）
parserOptions: {
ecmaVersion: 12
},
// 每个校验规则的开启或者关闭
rules: {
'no-undef': 'off'
},
// 列出可用的全局对象，不做检测。
globals: {
jQuery: 'readonly'
}
}
eslint在前端构建工具中的使用
gulp
const {src} = require('gulp');
const eslint = require('gulp-eslint');
export.default = function() {
return src(['scripts/*.js'])
.pipe(eslint())
// 在控制台输出检测错误
.pipe(eslint.format())
// 检测到lint错误，阻断构建
.pipe(eslint.failAfterError());
}
webpack
const ESLintPlugin = require('eslint-webpack-plugin');
module.exports = {
plugins: [new ESLintPlugin()],
};
rollup
import eslint from '@rollup/plugin-eslint';
export default {
input: 'main.js',
plugins: [
eslint()
]
};
与prettier结合
prettier是一个流行的代码格式化工具。
一般情况下，我们使用eslint都会配合prettier使用。prettier让我们自定义编写代码的规范，通过一些插件，让eslint的格式全是使用prettier中定义的格式验证。
Prettier认为，Lint规则分为两类：
-
格式优化类：max-len，no-mixed-spaces-and-tabs，keyword-spacing，comma- style···
-
代码质量类：no-unused-vars， no-extra-bind， no-implicit-globals， prefer- promise-reject-errors···
Prettier只关注第一类，且不会以报错的形式告知格式问题，而是允许开发者按自己的方式编写代码，但是会在特定时机（save，commit），将代码格式化为可读性最好的形式。
但是现在每个应用的cli都提供了eslint的选择，我们在创建项目的时候就可以直接继承，帮助我们可以快速的配置到lint，方便我们的开发。
stylelint
该库是对于css, sass, less等css预处理器的css进行语法检测的。
检测css我们需要安装stylelint-config-standard标准来对css语法进行检测。
// .stylelintrc.js
module.exports = {
extends: [
"stylelint-config-standard"
]
}
检测sass我也也需要安装对应的标准stylelint-config-sass-guidelines。
// .stylelintrc.js
module.exports = {
extends: [
"stylelint-config-standard",
"stylelint-config-sass-guidelines"
]
}
husky
在我们提交代码之前对代码进行检测，防止一些开发者未使用lint工具对代码进行检测。
所以我们就需要通过git hooks在代码提交前强制lint。
Git Hooks 介绍
Git Hook 也称之为 git 钩子，每个钩子都对应一个任务。
通过 shell 脚本可以编写钩子任务触发时要具体执行的操作。当我们执行对应的git操作，就会触发对应的钩子。
husky就是编写一个shell脚本放在git hooks中。
但是husky只是配合eslint做代码检测，不通过不允许提交，这种功能并不是很方便，所以我们需要让他自动修复，并提交。
lint-staged
当执行lint-staged命令时，设置一些文件的匹配，然后执行那些操作。
// package.json
{
"scripts": {
"lintjs": "eslint demo.js",
"lintstyle": "stylelint main.css",
"precommit": "lint-staged"
},
"husky": {
"hooks": {
"pre-commit": "npm run precommit"
}
},
"lint-staged": {
"*.js": [
"eslint",
"git add"
]
}
}