项目规范化记录篇
项目规范化的重要性不用多说了，直接进入正题。
EditorConfig
EditorConfig helps maintain consistent coding styles for multiple developers working on the same project across various editors and IDEs.
EditorConfig 有助于为跨各种编辑器和ide从事同一项目的多个开发人员维护一致的编码风格。
简单的来说，就是 editorconfig 就是为了磨平编译器之间的编码差异，保证编译器的行为与 .editorconfig 行为保持一致，且优先级高于编译器的默认配置（排除了个性化）。
作用对象：编辑器的配置，让你写出良好的代码
额外补充:
- 有些编辑器默认支持 editorConfig，如 webstorm；而有些编辑器则需要安装 editorConfig 插件，如 Sublime、VSCode等。
- 查找规则，当打开一个文件时，editorConfig 插件会在打开文件的目录和其每一级父目录查找.editorconfig 文件，直到有一个配置文件 root=true。
- editorConfig 不仅仅作用于 JavaScript 语言，还能作用于其他的语言。
配置选项：
创建文件 .editorconfig，配合插件或者编译器自带功能使用
# .editorconfig
root = true # 根目录的配置文件，编辑器会由当前目录向上查找，如果找到 `roor = true` 的文件，则不再查找
[*]
indent_style = space # 空格缩进,可选"space"、"tab"（推荐 space，更好的性能优化，丑化去掉space）
indent_size = 4 # 缩进空格为4个（indent_style=space 优先使用，没有再去使用 tab_width）
tab_width=4 # 缩进空格为4个（indent_style=tab 优先使用，没有再去使用 indent_size）
end_of_line = lf # 结尾换行符，可选"lf"、"cr"、"crlf"（不同系统(window,mac,linux)之间的差异，推荐使用 lf）
charset = utf-8 # 文件编码是 utf-8
trim_trailing_whitespace = true # 不保留行末的空格
insert_final_newline = true # 文件末尾添加一个空行
curly_bracket_next_line = false # 大括号不另起一行
spaces_around_operators = true # 运算符两遍都有空格
indent_brace_style = 1tbs # 条件语句格式是 1tbs
[*.js] # 对所有的 js 文件生效
quote_type = single # 字符串使用单引号
[*.{html,less,css,json}] # 对所有 html, less, css, json 文件生效
quote_type = double # 字符串使用双引号
[package.json] # 对 package.json 生效
indent_size = 2 # 使用2个空格缩进
Prettier
如果安装了prettier 插件，那么就会带默认的格式化。
// setting.json
// 设置编辑器的默认格式化工具为prettier
"editor.defaultFormatter": "esbenp.prettier-vscode",
// 为 javascript 语言指定格式化工具为 prettier（也可以设置其他的格式化，或者关闭-false）
"[javascript]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
ctrl+s 就会自动格式化。
上面，就只是针对 vscode编辑器（本身支持），那如果是使用 webstorm 呢，那么还能格式化吗？答案很显然。
那么就需要通过第三方包，来配置相同规则，保持格式化。
安装
pnpm add prettier -D
配置 .prettierrc
在根目录下创建 json文件 或则 js文件
// .prettierrc json文件
{
"useTabs": false,
"tabWidth": 2
}
// .prettierrc.js js文件 （可以写备注，比较习惯）
module.exports = {
trailingComma: "es5", // 在对象或数组最后一个元素后面是否加逗号（在ES5中加尾逗号）
useTabs: false, //使用空格代替tab缩进
tabWidth: 2, // 缩进长度
semi: false, // 句末使用分号
singleQuote: true, // 单引号（JSX会忽略这个配置）
jsxSingleQuote: true, // jsx中使用单引号
arrowParens: 'always', //单参数箭头函数参数周围使用圆括号-eg: (x) => x
}
配置 .prettierignore
/node_modules/**
/dist/*
**/*.svg
**/*.sh
/public/*
全局格式化
如果项目的每个文件，都需要要格式化，就可以使用全局格式化命令。
// package.json
"scripts": {
"prettier": "prettier --write ."
},
执行 pnpm run prettier 之后，就会针对项目的所有文件（除了忽略文件）都会进行格式化。
vite 格式化无效
vite 构建工具兴起，创建项目也可以通过 vite 来进行创建，在配置的时候，会出现一点问题，可能会使 prettier 不起作用。
问题发现： 在配置 prettier 发现没有效果，又去执行了 pnpm run prettier 发现报错，
报错信息：Invalid configuration file
.eslintrc.cjs: require() of ES Module…错误原因： 使用 vite 创建的项目，package.json 中存在 type: ‘module’, 那么就会使所有的 js 文件使用 ESModule 规范，那么在 js 文件中使用 commonjs 规范就是报错的
解决方案(两种) ：
- 去掉 package.json 中的 type: ‘module’
- .js 后缀名改为 .cjs 后缀名 (推荐)
ESLint
ESLint 是一个语法规则和代码风格的检查工具，可以用来保证写出语法正确、风格统一的代码。
vscode 也是需要安装 eslint 插件的。并且也需要再项目中安装 eslint。
安装
pnpm add eslint -D
创建配置文件
现在是采用 pnpm create @eslint/config，以前是采用 eslint --init(不知道原因，可能是版本升级)。当执行之后，就会存在下面的一些列步骤，根据自己需求配置即可。
以及根据上面的自定义配置，可能还需要安装一些插件。
安装完成之后， 就会生成一个 .eslintrc.js 或者 .eslintrc.cjs文件：
module.exports = {
// 项目配置文件查找，如果找到 root 为true，就停止查找
"root": true,
// env 启用的环境
"env": {
"es2021": true,
"browser": true,
"node": true
},
// 继承的规则 （ 字符串 或则 字符数组[后面的配置继承前面的配置] ）
"extends": [
"eslint:recommended", // 启用一系列核心规则 eslint规则页面展示
"plugin:react/recommended", // eslint-plugin-react的规则配置
"plugin:@typescript-eslint/recommended" // ts规则配置
],
// 指定让 ESLint 使用自定义的解析器 @typescript-eslint/parser
"parser": "@typescript-eslint/parser",
"parserOptions": {
// 想使用额外的语言特性
"ecmaFeatures": {
"jsx": true //启用jsx
},
// emcaVersion用来指定你想要使用的 ECMAScript 版本
"ecmaVersion": 13,
// 设置为 "script" (默认)或"module"（如果你的代码是 ECMAScript 模块)
"sourceType": "module"
},
// plugins与上面的继承的配置，一一对应（不知道是不是这样理解的）
"plugins": [
"react",
"@typescript-eslint"
],
// 这里主要就是我们规则的配置对象
"rules": {
}
};
plugins: 插件。插件是一个npm 包，通常输出规则，可以提供处理器。
parser: 解析器。 eslint的默认解析器： Espree
以下解析器与 ESLint 兼容：
EsprimaBabel-ESLint: 一个对Babel解析器的包装，使其能够与 ESLint 兼容。@typescript-eslint/parser: 将 TypeScript 转换成与 estree 兼容的形式，以便在ESLint中使用。
parserOptions 解析器的配置。
rules 我们平时配置规则的对象。
ESLint 的配置规则
规则配置：
"off" 或 0 – 关闭规则
"warn" 或 1 – 开启规则，使用警告级别的错误：warn (不会导致程序退出)
"error" 或 2 – 开启规则，使用错误级别的错误：error (当被触发的时候，程序会退出)
"rules": {
eqeqeq: "off",
curly: "error"
}
// 等价于
"rules": {
eqeqeq: 0,
curly: 2,
quotes: ["error", "double"] // 也可以是个数组，数组第一个：表示规则的严重程度（数字或字符串）
}
当然具体配置规则，是根据需求查阅文档在配置属性的，就需要平时慢慢积累。
ESLint 配置脚本
{
"script": {
"lint": "eslint --fix --ext .js,.ts,tsx,jsx src"
// --fix 自动修复
// --ext 其他的文件后缀名（默认js）
// src 检查src目录下的文件
}
}
ESLint 与 Prettier 冲突
eslint 和 prettier 都能进行代码格式化，当一些规则存在冲突的时候，当格式化时，就不知道采用哪种规则，那么怎么解决呢？
当使用 eslint 代码格式化时，针对可能存在相同冲突的规则，关闭 eslint 的相关规则，采用 prettier 的规则。
实现该功能：
- eslint-config-prettier: 关闭 eslint 的相关冲突的格式化规则。
- eslint-plugin-prettier: 把 prettier 作为 eslint 的插件，采用 prettier 的格式化规则。该插件需要依赖 prettier。
pnpm add eslint-config-prettier eslint-plugin-prettier -D // 开发时依赖
// .eslintrc.js
module.exports = {
"extends": [ // 后面的相同规则覆盖前面的
"eslint:recommended", // 启用一系列核心规则 eslint规则页面展示
"plugin:react/recommended", // eslint-plugin-react的规则配置
"plugin:@typescript-eslint/recommended", // ts规则配置
"plugin:prettier/recommended" // 推荐使用prettier的规则（处理兼容的）
],
// extends 里面不能有空格
}
Q&A
上面的三种配置，目的都是为了项目代码规范化，那么为什么？
- 为什么有了 eslint 还需要 prettier?
作用功能不一样：
- ESLint 针对代码质量进行检查 和 针对代码风格进行检查。
- Prettier 针对代码风格进行检查
作用对象不一样：
- ESLint 仅仅针对 js / jsx /ts 检查，如果支持其他，插件配置，比较麻烦。
- Prettier 针对多文件格式进行检查。
所以两者需要配合使用：多文件质量和风格检查。
- 为什么有了 prettier 还需要 editorconfig?
作用时机不一致：
- editorconfig 作用于编译器的配置，让你写出良好的代码。（写代码之前）
- prettier 作用于写好的代码，然后格式化。（写代码之后）
Git Husky
在项目中，我们已经使用了 eslint 的一些列规范，来约束我们的代码格式。但是呢？并不能保证我们每个人的代码都是符合规范的（比如：没有对一些文件进行ctrl + s格式化 ），然后就进行了commit的操作，那么就导致了仓库中的代码就是不会符合规则的。
那么针对这种问题该如何解决呢？
那么我们需要在执行 git commit 命令之前（pre-commit）的时候对其进行校验，如果不符合eslint规范，那么自动通过规范进行修复；（执行 eslint --fix类似操作）
husky是一个 git hook工具，可以帮助我们触发 git 提交的各个阶段：pre-commit、commit-msg、pre-push。那么就可以利用这点，进行格式检查和修复。
安装：
pnpm add husky -D
准备：
// package.json
{
"script": {
"prepare": "husky install" // 虽然该命令可以通过命令生成，但是我感觉比较麻烦，就手动书写
}
}
执行该脚本(pnpm run prepare)，就在项目中生成一个.husky 文件夹。
再次执行脚本(npx husky add .husky/pre-commit "pnpm run lint")，就会在 .husky 文件夹下创建 pre-commit 文件。
pnpm run lint 就是用于 commit 之前的检查
// pre-commit
#!/bin/sh
. "$(dirname "$0")/_/husky.sh"
pnpm run lint
该文件就是用来拦截commit，在执行commit之前，调用npm run lint脚本，格式化代码之后，提交。
lint-staged
在上面的 .husky 中执行的命令为 pnpm run lint，是针对所有文件的校验。但是在开发中，提交代码往往只是提交修改的内容，就没有必要对所有的内容进行检查，只需要检查修改的部分即可。
安装：
pnpm add lint-staged -D
配置： package.json 或者 配置文件
module.exports = {
"lint-staged": {
"*.{vue,js,ts,jsx,tsx,json}": "eslint --fix",
"*.md": [
"prettier --write"
]
},
}
修改 .husky/pre-commit 文件内容
pnpm exec lint-staged # 替换pre-commit 文件中的 pnpm run lint
Git 提交规范
在团队合作的项目开发中，git 是我们首选的工具。
git add .
git commmt -m '提交信息'
git push
在上面的步骤中，commit的命令的提交信息 是比较重要的。因为在版本回退的时候就非常的有作用了。
所以需要对提交信息 做出相应的规范。
这篇文章，详细的讲述了git commit的提交规范。
zhuanlan.zhihu.com/p/182553920
git commit 提交规范
<type>(<scope>): <subject>
type(必填): 提交信息的类型。
scope(选填)： 提交影响的范围
subject(必填)： 本次的详细描述
Type的类型
| type | 作用 |
|---|---|
| feat | 新增特性 (feature) |
| fix | 修复 Bug(bug fix) |
| docs | 修改文档 (documentation) |
| style | 代码格式修改(white-space, formatting, missing semi colons, etc) |
| refactor | 代码重构(refactor) |
| perf | 改善性能(A code change that improves performance) |
| test | 测试(when adding missing tests) |
| build | 变更项目构建或外部依赖（例如 scopes: webpack、gulp、npm 等） |
| ci | 更改持续集成软件的配置文件和 package 中的 scripts 命令，例如 scopes: Travis, Circle 等 |
| chore | 变更构建流程或辅助工具(比如更改测试环境) |
| revert | 代码回退 |
git commit 提交方式
方式一：手动填写(个人爱好)
git commit -m 'feat(login): 修改了登录接口'
方式二： 工具提交（commitizen）
Commitizen 是一个帮助我们编写规范 commit message 的工具；
1、安装：
yarn add commitizen cz-conventional-changelog -D
2、在package.json中配置
"config": {
"commitizen": {
"path": "./node_modules/cz-conventional-changelog"
}
}
3、使用 命令 npx cz
第一步： 选择 commit type
第二步：影响的范围
第三步：commit 描述信息（不能超过87字符）
第四步：长描述（一般不写）
第五步：是否是重大的变动（默认为NO）
第六步：是否影响某个open issue（一般针对开源项目）
上面的一些列操作之后，就会生成一个commit信息（是不是感觉比较的麻烦）
git commit 信息验证（commitlint）
虽然有了上面的一些git commit 提交规则，但是并不是所有都会遵循，还是随意提交，那么就需要限制。
使用 commitlint 来验证提交的规则，是否符合规范。
安装：
pnpm add @commitlint/config-conventional @commitlint/cli -D
使用：
在根目录创建commitlint.config.js文件，配置commitlint
module.exports = {
extends: ['@commitlint/config-conventional']
}
使用 husky 生成 commit-msg 文件，验证提交信息。
npx husky add .husky/commit-msg "npx --no-install commitlint --edit $1"
配置好之后，就能验证提交信息的规则了。
vscode 配置
vscode 使用 eslint
- 在 vscode 安装 eslint 插件，并且启用。
// vscode ===> setting.json
{
"eslint.enable": true // 开启 eslint 检查
}
- 在项目中或者全局中安装 eslint 模块，并且也需要安装配置项的依赖插件。
- 配置规则文件：.eslintrc.js 或者 .eslintrc.json，或者在 package.json 中的 eslintConfig 配置。
方法一：eslint 格式化
方法二：执行 lint 命令
pnpm run lint都会去自动读取配置文件，进行检查，发现不满足要求的地方，就是使用
波浪线(红色，黄色)进行标记。
上面三步都配置好了，eslint 也就可以正常工作了，但是呢？
当发现了异常，只会给开发者看，需要开发者手动去解决，不会主动去修改，那么怎么实现保存时，自动格式化呢？
"editor.codeActionsOnSave": {
// 使用eslint来fix，包括格式化会自动fix和代码质量检查会给出错误提示
"source.fixAll.eslint": true,
- "source.fixAll": true // 表示所有提供的代码格式工具进行代码格式化，就是不仅仅只是eslint格式化，还是其他的也会进行格式化（不建议配置）
}
配置了，保存的时候也就会自动格式化了。
vscode 使用 prettier
- 不需要在项目中安装 prettier 模块，只需要安装 vscode 提供的 prettier 插件即可。（插件名称：prettier-code formmater）。
- 配置，启用 prettier 。
// 在vscode中安装Prettier插件并启用，两种形式
// - 同时需要设置Prettier为对应的代码默认格式化，
{
"editor.defaultFormatter": "esbenp.prettier-vscode" // 默认的代码格式化工具
}
// - 或者将其设置为指定语言的代码格式化。
"[javascript]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[typescript]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
当配置了，prettier 也就会生效了，但是呢？也还是不会在保存的时候自动格式化，那么该怎么配置呢？
分为两种情况，针对 prettier.requireConfig 配置：
- 如果为
prettier.requireConfig: true，表明需要配置文件，即在根目录文件夹下存在配置文件.prettierrc或者.editorconfig，读取配置进行格式化；如果没有配置文件，就会报错。 - 如果为
prettier.requireConfig: false，表明不需要配置文件，即根目录下不需要配置文件，使用默认的格式化规则。但是哈，如果存在配置文件，也会自动的去读取。
{
"editor.formatOnSave": true, // 开启保存文件自动格式化代码
"editor.defaultFormatter": "esbenp.prettier-vscode", // 默认的代码格式化工具
"prettier.requireConfig": true // 需要Prettier的配置文件
}
优先级：
.prettierrc>.editorconfig>vscode 默认规则。不是覆盖而是合并，冲突再采用优先级的规则。
.prettierrc和.editorconfig同时存在时，二者内容会进行合并，若配置项有冲突，这.prettierrc的优先级更高。
