前言
本系列文章是为了帮助没有直接上手（或上手比较困难）做项目能力的初级前端开发工程师采用 V3 Admin Vite 开源模板来编写业务代码。
如果你是一个有经验的朋友，那建议你直接阅读文档即可：V3 Admin Vite 中文文档，因为本系列教程节奏偏慢。
本系列文章的同步视频教程版本地址：B 站（群友好心录制）
文章目的
本文将带你学习该项目是基于哪些主流的社区规范来开发的，并做了哪些和代码规范相关的配置。
Begin
命名规范
因为 Vue 风格指南 中有提到：单文件组件文件名应该要么始终是单词大写开头 (PascalCase)，要么始终是横线连接 (kebab-case)
本 V3 Admin Vite 项目的前身，也就是 V3 Admin 项目，在早期的时候，就是全采用的 短横线连接 的命名方式，但是现在已经将 Component 组件命名改为 大驼峰 命名方式。
Components
所有的 Component，也就是组件，都采用单词大写开头的 大驼峰 命名方式 (PascalCase)。
比如在 @/components 目录下的公共组件：
@/components/Screenfull/index.vue@/components/SvgIcon/index.vue@/components/ThemeSwitch/index.vue
看上面的例子，也就是说，如果是 index.vue，那么 index.vue 是不用大驼峰命名 的。
如果不是 index.vue，比如下面这个 NotifyList.vue 组件，那么就需要 大驼峰 命名：
@/components/Notify/index.vue@/components/Notify/NotifyList.vue
即便是在 views 目录下只属于某个页面的组件，也同样需要遵守大驼峰命名：
@/views/error-page/components/ErrorPageLayout.vue@/views/permission/components/SwitchRoles.vue
Views
放在 @/views 目录下代表着页面和路由的 .vue 文件或目录，它们一律采用 短横线连接 (kebab-case) 的命名方式，比如：
@/views/table/element-plus/index.vue@/views/table/vxe-table/index.vue@/views/error-page/404.vue@/views/error-page/403.vue@/views/hook-demo/use-fetch-select.vue@/views/hook-demo/use-fullscreen-loading.vue
那，为什么 Component 采用大驼峰，View 采用短横线？
主要因为这两点：
- 能更好的区分 Component 和 View
- 导入 Component 时，采用的就是大驼峰方式
- 符合社区主流命名习惯
Hooks / Composables
采用 小驼峰 (camelCase)，比如：
@/hooks/useTheme.ts@/layout/hooks/useResize.ts
Props
在声明 prop 的时候，其命名应该始终采用 小驼峰 (camelCase)，而在模板和 JSX 中应该始终使用 短横线连接 (kebab-case)，比如：
以 @/components/Screenfull/index.ts 组件为例：
声明定义 Props
const props = defineProps({
/** 全屏的元素，默认是 html */
element: {
type: String,
default: "html"
},
/** 打开全屏提示语 */
openTips: {
type: String,
default: "全屏"
},
/** 关闭全屏提示语 */
exitTips: {
type: String,
default: "退出全屏"
}
})
在 @/layout/components/NavigationBar/index.ts 模板中使用该组件并向 Props 传递数据
<Screenfull v-if="showScreenfull" element=".app-main" open-tips="内容区全屏" class="screenfull" />
其他 .ts 或 .js 文件
一般采用 短横线连接 的命名方式即可
总结
虽然命名方式不是固定的，但还是希望每一个项目都采用相对统一的规范（最好是社区主流），这样开发出来的项目的目录结构才会非常清爽整洁。
代码规范
基本上学习一下 Vue 风格指南 就足够了，其中我认为比较重要的几点：
- prop 的定义应该尽量详细，至少需要指定其类型
- 在组件上总是必须用 key 配合 v-for，以便维护内部组件及其子树的状态
- 避免 v-if 和 v-for 用在一起
- 命名规范相关的所有内容
我再补充一个非常有用的个人经验：
在对 v-for 循环出来的列表有删除操作的时候，切记不要轻易使用数组下标 index 当做 key！
如果你看见这句话时并不是强烈的认同，反而发出了疑问，那说明你可能并不知道其中的坑。那我就更加建议你无论如何都要使用唯一的 id 作为 key 值，而不是 index。
如果你想快速搞懂这个问题，那你可以阅读一下这篇回答 Vue2.0 v-for 中 :key 到底有什么用？
Git 提交规范
现在社区一般都大致遵循这个规范：
- feat: 增加新的业务功能
- fix: 修复业务问题/BUG
- perf: 优化性能
- style: 更改代码风格, 不影响运行结果
- refactor: 重构代码
- revert: 撤销更改
- test: 测试相关, 不涉及业务代码的更改
- docs: 文档和注释相关
- chore: 更新依赖/修改脚手架配置等琐事
- workflow: 工作流改进
- ci: 持续集成相关
- types: 类型定义文件更改
- wip: 开发中
当然，上面这里的话只是规范你提交的描述信息。至于何时提交一个 commit 的话，我们简单采用一个原则：完成一件事情，就提交一次 commit。而不是等到你写完一整天的代码后，才在下班前只提交一次。
注释规范
由于项目采用 TS 5.x 进行开发，为了获得更好的 TS 提示，项目采用了大量的 /** xxx */ 注释，它的优点就是鼠标放上去会有注释显示出来：
代码校验与格式化
项目已经配好了一套格式化校验规则和流程，是基于 eslint + prettier + husky + lint-staged 这四个依赖的。我知道有许多人不爱将 ESlint 和 Prettier 一起使用，因为会发生冲突，但是大家放心，该项目本身已经完全配置好，不会有冲突的情况出现。
IDE 环境
请参考手摸手系列教程第一篇：【V3 Admin Vite】教程一：环境、下载、运行项目 配置好开发环境，重点是一定要安装项目根目录下 .vscode 文件夹中配置好的推荐的插件，其中的 ESlint 和 Prettier 插件就是代码校验和格式化必备的。
另外请注意：Vue3 项目对应的是 Volar 插件，记得禁用 Vue2 的 Vetur 插件！
项目配置
ESlint
package.json文件的devDependencies中有所需的 ESlint 依赖包ESlint的配置文件是根目录下的.eslintrc.cjs，它里面定义了很多校验规则ESlint的忽略文件是根目录下的.eslintignore，它里面定义的目录和文件都不会被 ESlint 检查
Prettier
package.json文件的devDependencies中有所需的 Prettier 依赖包Prettier的配置文件是根目录下的prettier.config.js，它里面定义了很多格式化规则Prettier的忽略文件是根目录下的.prettierignore，它里面定义的目录和文件都不会被 Prettier 格式化
上面提到的这些，你都可以不用去特意的改动它，因为都已经配置好了，但是你必须要清楚它们在什么地方，是干什么用的。这样后续遇到问题时才好定位。
自动校验和格式化
我已经在 .vscode/settings.json 配置文件中写好了自动格式化规则（只要你下载本项目，就会优先采用该规则）
settings.json 全部规则如下：
{
"editor.codeActionsOnSave": {
"source.fixAll.eslint": "explicit"
},
"[vue]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[javascript]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[typescript]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[json]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[jsonc]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[html]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[css]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[scss]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
}
}
其中比较重要的就是在保存代码时，自动进行 ESlint 修复代码：
"editor.codeActionsOnSave": {
"source.fixAll.eslint": "explicit"
}
并且在 ESlint 的 .eslintrc.cjs 配置文件中，我们也做了 Prettier 规则适配。也就是说，采用 ESlint 校验和修复代码时，也会顺便校验和修复不满足 Prettier 规则的代码。
具体到 .eslintrc.cjs 配置文件里面的规则就是：
// .eslintrc.cjs 文件
extends: [
"@vue/prettier"
]
rules: {
"prettier/prettier": [
"error",
{
endOfLine: "auto"
}
]
}
而 settings.json 中剩下的一些规则：
{
"[vue]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[javascript]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[typescript]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[json]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[jsonc]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[html]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[css]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[scss]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
}
}
表示的是在进行 vue、javascript、typescript、json、jsonc、html、css、scss 文件手动格式化时，采取 Prettier 来进行格式化。
Git 提交代码时自动校验和格式化
该功能来自 husky 依赖和 lint-staged 依赖的配合使用，
由 husky 接管 git hooks 钩子，在提交代码时，由 lint-staged 检查并修复本地暂存代码。
本质上检查的规则依旧是 ESlint + Prettier，lint-staged 配置如下：
// package.json 文件
"lint-staged": {
"*.{vue,js,jsx,ts,tsx}": [
"eslint --fix",
"prettier --write"
],
"*.{css,less,scss,html,md}": [
"prettier --write"
],
"package.json": [
"prettier --write"
]
}
当然，这些配置好了的规则一般也不用你去修改，大多数情况下你就直接使用就行了。
这个功能算是一种兜底，因为在你保存代码时，ESlint 和 Prettier 就会工作了。防止的是有些用户没按照要求下载对应插件导致保存代码时没能自动修复和格式化，这时候直接提交会破坏远程仓库的代码格式统一，所以才有了这个兜底操作
