前端工程化之规范化
为什么要有规范标准
- 开发需要多人协同
- 开发者不同的编码喜好
- 统一标准，降低维护成本
哪里需要规范化标准
- 代码、文档、日志
- 开发过程中的人为成果
- 代码标准化决定项目质量，最为重要
如何实施规范化
- 人为的标准约定
- 通过工具实现Lint
ESLint
安装
安装：npm install eslint -D，安装后就会在node_modules/.bin/下有一个CLI程序。
使用
先配置，再检查
使用eslint --init生成配置文件，可以是JavaScript，也可以是JSON文件。
使用npx eslint 对file进行eslint检查。
使用npx eslint 来自动纠正检查中的问题。
配置文件
standard风格下，默认的配置文件位于node_modules/eslint-config-standard/eslintrc.json。
env: 用来设置代码的运行环境。
"env": {
"es6": true,
"node": true
}
其中，定义了如下的全局变量
"globals": {
"document": "readonly",
"navigator": "readonly",
"window": "readonly"
},
因此，即使是browser环境设置为false，以上的全局变量也是可读的，在代码中使用不会报错。
下图给出了所有能够运行的环境和对应的说明。
这些环境并不是互斥的，可以同时开启。
extends: 继承共享的配置
比如，定义一个公共的配置文件，可以让其他配置文件继承。
可以是数组，用来继承多个配置。
可以在 npm官方 搜索 “eslint-config” 使用别人创建好的配置
parserOptions: 语法解析器的配置
- 用来启用某个版本的语法解析器，从而控制代码中使用的语法。
parserOptions: { // 启用es语法版本 ecmaVersion: 5, // JS文件是script还是module的形式 sourceType: 'script' } - 语法解析器与env运行环境不同，语法解析器仅仅是以某个版本的语法为基础来Lint代码，而env则提供该环境下的API。
比如，将env.es6设为false，parserOptions.ecmaVersion设为2015，如果代码中包含有Promise等ES6环境下的全局变量或API，则检查会对Promise报错，因为当前环境设定不是ES6，Promise会变为一个未声明变量。env: { browser: true, es6: false }, extends: [ 'standard' ], parserOptions: { ecmaVersion: 2015, sourceType: 'module' },
rules：校验规则
globals：额外的全局成员
配置注释
将配置通过注释写在要Lint的代码中。
通常用于针对特定的代码，采用特定的配置规则，这些特定规则与配置文件中的已定规则不同。
参考
const str = '${name} is a coder' // eslint-disable-line no-template-curly-in-string
console.log(str)
共享配置
- 共享配置也是一个npm包，通常导出一个配置对象。
- 要确保这些包安装在 ESLint 能请求到的目录下
共享配置要导出一个如下的配置对象
module.exports = {
globals: {
MyGlobal: true
},
rules: {
semi: [2, "always"]
}
};
共享配置的使用
可分享配置被设计和 .eslintrc 文件的 extends 特性一起使用。使用模块名称作为 extends 取值而不是文件路径
{
"extends": "eslint-config-myconfig"
}
可以省略eslint-config-，ESLint 会自动找到
{
"extends": "myconfig"
}
插件
- 插件是一个 npm 包，通常输出规则。一些插件也可以输出一个或多个命名的配置。
- 每个插件是一个命名格式为 eslint-plugin-
的 npm 模块 - 在 ESLint 中，插件可以暴露额外的规则以供使用。为此，插件必须输出一个 rules对象，包含规则 ID 和对应规则的一个键值对
插件的使用
在配置文件的plugins字段中注册插件，在extends字段中扩展插件的规则（或配置）
- plugins 属性值 可以省略包名的前缀 eslint-plugin-
- extends 属性值可以由以下组成：
- plugin:包名 (省略了前缀，比如，react)
- /
- 配置名称 (比如 recommended
{
"plugins": [
"react"
],
"extends": [
"eslint:recommended",
"plugin:react/recommended"
],
"rules": {
"no-set-state": "off"
}
}
与构建工具的集成
集成到gulp构建流
- 使用
gulp-eslint包 - 生成配置文件
- 按照官网给出的方法来集成
const {src, task} = require('gulp');
const eslint = require('gulp-eslint');
task('default', () => {
return src(['scripts/*.js'])
// eslint() attaches the lint output to the "eslint" property
// of the file object so it can be used by other modules.
.pipe(eslint())
// eslint.format() outputs the lint results to the console.
// Alternatively use eslint.formatEach() (see Docs).
.pipe(eslint.format())
// To have the process exit with an error code (1) on
// lint error, return the stream and pipe to failAfterError last.
.pipe(eslint.failAfterError());
});
集成到webpack打包构建流
- 使用Loader机制，安装
eslint-loader - 生成eslint配置文件
- 集成到webpack中
{
test: /\.js$/,
exclude: /node_modules/,
use: 'eslint-loader',
// 表示前置loader，表示对于.js文件类型，eslint-loader优先处理
// enforce用来强制调整loader的顺序
enforce: 'pre'
},
与React一起工作的相关配置
1:8 error 'React' is defined but never used no-unused-vars
4:8 error 'App' is defined but never used no-unused-vars
针对上述报错，实际上React是需要加载React的，而App同样在JSX编译为js中使用了，因此要配置eslint使得这种情况可以允许。
- 安装
eslint-plugin-react - 配置eslintrc.js文件：两种配置方式分别如下
-
可以配置插件和对应的规则
rules: { 'react/jsx-uses-react': 2, 'react/jsx-uses-vars': 2 }, plugins: [ 'react' ] -
也可以直接配置继承
extends: [ 'standard', 'plugin:react/recommended' ],
-
现代化项目集成ESLint
现代项目中使用的CLI程序已经将ESLint都集成到工作流了，如vue-cli，create-react-app等。
ESLint检查TypeScript
在使用npx eslint --init生成配置文件时，选择目标为TypeScript。
module.exports = {
// 以下两个选项是针对TypeScript，parser是TS语法的解析器
parser: '@typescript-eslint/parser',
plugins: [
'@typescript-eslint'
],
}
与Prettier一起使用
ESLint并不是重点做代码风格校验的工具，而代码风格校验正是Prettier的强项，因此两者一起使用来强制规范代码风格。
安装
npm i -D prettier
npm i -D eslint-plugin-prettier
eslint-plugin-prettier插件会调用prettier对你的代码风格进行检查，其原理是先使用prettier对你的代码进行格式化，然后与格式化之前的代码进行对比，如果过出现了不一致，这个地方就会被prettier进行标记。
在eslintrc.js配置文件中进行对应的配置
//.eslintrc.js
{
"plugins": ["prettier"],
"rules": {
// 表示被prettier标记的地方抛出错误信息
"prettier/prettier": "error"
}
}
推荐配置
安装eslint-config-prettier
npm i -D eslint-config-prettier
能够关闭一些与格式相关的ESlint规则。
使用的时候需要确保，这个配置在extends的最后一项。
配置
//.eslintrc.js
{
"extends": ["plugin:prettier/recommended"]
}
配置做了三件事
- 启用eslint-plugin-prettier的规则
- 设定prettier/prettier 规则为 “error”
- 扩展eslint-config-prettier的配置
StyleLint
- 检查CSS代码
- 提供默认的代码检查规则
- 提供CLI工具快速调用
- 通过插件支持Sass、Less、PostCSS
- 支持Gulp或webpack的集成
使用
- 安装
npm install --save-dev stylelint - 创建配置文件
.stylelintrc.js，也可以是json文件 - 安装语法风格库或插件
stylelint-config-standard：检查CSS代码的标准语法stylelint-config-sass-guidelines：检查Sass代码的语法
// .stylelintrc.js
module.exports = {
extends: [
'stylelint-config-standard',
'stylelint-config-sass-guidelines'
]
}
Prettier
前端代码格式化工具
- 安装
npm install prettier -D，同样会生成一个CLI程序 - 使用
npx prettier将--write
Git Hooks与ESLint集成
- GitHooks通过shell脚本可以编写hooks任务来触发一些需要的操作。
- 在提交前先进行Lint操作。
Husky实现Git Hooks的使用需求
在不编写shell脚本的情况下，也能使用git hooks。
-
安装husky：
npm install husky -D，安装之后，就会在.git/hooks生成很多hooks脚本文件。 -
配置husky: 在package.json中配置husky字段
"husky": { "hooks": { "pre-commit": "npm run test" } }
这里配置了"pre-commit"，也就是在git commit之前运行npm run test。
lint-staged：对staged的代码进行Lint
如果每次提交都去Lint很多代码，无疑是很麻烦，且很多代码可能并不需要Lint，毕竟代码需要渐进式地更新，而非整体推倒重来。因此，为了只Lint准备提交的代码，可以使用lint-staged来做。
使用git add 后，file就被git记录到了staged（索引区）。我们只要将这些文件Lint即可。
安装：npm install lint-staged -D
在package.json中配置lint-staged字段
"lint-staged": {
// 键为目标文件，可以是glob
// 值为在命令行中对键定义的目标进行的任务，可以是一个数组，按数组元素的顺序进行操作，流式操作
"*.js": [
"eslint",
// 实际上，这里的git add 不再需要，默认就会将操作后的更改更新到索引区
"git add"
]
}
Husky与lint-staged协同
在git commit 之前启动lint-staged。
"scripts": {
"precommit": "lint-staged"
},
"husky": {
"hooks": {
"pre-commit": "npm run precommit"
}
},
"lint-staged": {
"*.js": [
"eslint"
]
}