基于Vue项目搭建规范

在团队协作中，为避免低级 Bug、以及团队协作时不同代码风格对彼此造成的困扰与影响。如果项目中没有统一的规范就会导致代码风格的五花八门，不利于代码的阅读和维护。所以会预先制定编码规范。

一、项目创建

vue create vue3-ts-cms

• 选择第三个选项，手动选择特性

• 选择图中的几个特性

• 选择vue3版本

• 其余的如下图

二、集成 editorconfig 配置

editorConfig 可以帮助我们在不同 IDE 编辑器上对同一项目 多人开发制定统一的编码风格

举个🌰

比如说：我们现在创建出来一个项目，这个项目是多人在开发，多人开发的情况下就有可能出现这样情况：

• 张三、李四、王五都在开发这个项目。但是可能会出现这样一个问题：张三用的是windows电脑，李四用的是mac电脑、王五也是用的windows电脑。

• 在不同的操作系统下面，对于 Enter(回车) 来说是不一样的，到时候在显示的时候是不一样的，所以类是于这样的风格我们希望把他统一起来，只要敲回车我们就统一成对应的风格。

• 另一个是我们的编辑器：比如张三喜欢用 VSCode、李四喜欢用 WebStorm, 有可能李四在用WebStorm的时候编辑器配置的的缩进是用Tab键缩进的。 tab-> 4个空格 那就意味着李四编写的所有代码缩进都是4个空格。

• 张三VSCode编辑器配置的缩进是两个空格。王五配置的缩进也是 tab键 tab->普通的tab缩进 那么三个人的代码风格是不一样的，提交到代码仓库里面，张三把李四的代码拉下来，拉下来之后会发现 缩进为啥全是四个空格，然后给他改掉吧，改了半天太麻烦了。李四把张三的代码拉下来也是一样，觉得太乱了。最主要的原因就是编辑器风格不一样，所以导致代码也不一致。

• 所以我们要保证代码风格要保持一致： 我们就要从项目搭建的时候就规定好是否用tab键，tab键用代表几个空格；比如在每个文件写完代码要不要有个控行等等，我们要在一开始就规定好。

1、首先我们需要在项目目录下创建出来这样一个 .editorconfig 文件。不管是我们 VSCode 还是 WebStorm 都会默认读取这个文件的，他会默认看一下项目里有没有这个文件，如果有这个文件 就会读取这个文件

# @see: http://editorconfig.org

root = true

[*] # 表示所有文件适用
charset = utf-8 # 设置文件字符集为 utf-8
end_of_line = lf # 控制换行类型(lf | cr | crlf)
insert_final_newline = true # 始终在文件末尾插入一个新行
indent_style = tab # 缩进风格（tab | space）
indent_size = 2 # 缩进大小
max_line_length = 130 # 最大行长度

[*.md] # 表示仅 md 文件适用以下规则
max_line_length = off # 关闭最大行长度限制
trim_trailing_whitespace = false # 关闭末尾空格修剪

2、VSCode 需要按照一个这样的插件：editorconfig 在VSCode 才会生效；WebStorm是集成开发环境 不需要安装 默认支持

二、 使用 prettier 工具

Prettier 是一款强大的代码格式化工具，支持 JavaScript、TypeScript、CSS、SCSS、Less、JSX、Angular、Vue、GraphQL、JSON、Markdown 等语言，基本上前端能用到的文件格式它都可以搞定，是当下最流行的代码格式化工具。

1、首先我们需要安装这个插件 Prettier

2、安装 prettier

npm install prettier -D // 开发时依赖 -D 

3、创建 .prettierrc

比如说我们是需要单引号还是双引号、每段代码结尾需不需要封号 ;、对象最后一个属性后面要不要加逗号呢？ 具体需要什么样的格式我们可以在配置的 prettier 文件里设置；

// @see: https://www.prettier.cn

module.exports = {
	// 超过最大值换行
	printWidth: 130,
	// 缩进字节数
	tabWidth: 2,
	// 使用制表符而不是空格缩进行
	useTabs: true,
	// 结尾不用分号(true有，false没有)
	semi: true,
	// 使用单引号(true单双引号，false双引号)
	singleQuote: false,
	// 更改引用对象属性的时间 可选值"<as-needed|consistent|preserve>"
	quoteProps: "as-needed",
	// 在对象，数组括号与文字之间加空格 "{ foo: bar }"
	bracketSpacing: true,
	// 多行时尽可能打印尾随逗号。（例如，单行数组永远不会出现逗号结尾。） 可选值"<none|es5|all>"，默认none
	trailingComma: "none",
	// 在JSX中使用单引号而不是双引号
	jsxSingleQuote: false,
	//  (x) => {} 箭头函数参数只有一个时是否要有小括号。avoid：省略括号 ,always：不省略括号
	arrowParens: "avoid",
	// 如果文件顶部已经有一个 doclock，这个选项将新建一行注释，并打上@format标记。
	insertPragma: false,
	// 指定要使用的解析器，不需要写文件开头的 @prettier
	requirePragma: false,
	// 默认值。因为使用了一些折行敏感型的渲染器（如GitHub comment）而按照markdown文本样式进行折行
	proseWrap: "preserve",
	// 在html中空格是否是敏感的 "css" - 遵守CSS显示属性的默认值， "strict" - 空格被认为是敏感的 ，"ignore" - 空格被认为是不敏感的
	htmlWhitespaceSensitivity: "css",
	// 换行符使用 lf 结尾是 可选值"<auto|lf|crlf|cr>"
	endOfLine: "auto",
	// 这两个选项可用于格式化以给定字符偏移量（分别包括和不包括）开始和结束的代码
	rangeStart: 0,
	rangeEnd: Infinity,
	// Vue文件脚本和样式标签缩进
	vueIndentScriptAndStyle: false
};

四、创建忽略文件 .prettierignore

还有一些文件我们是不希望对它做各式化的，这时候我们可以把这些文件忽略掉。这时候我们可以再配置一个 .prettierignore 文件

/dist/*
.local
.output.js
/node_modules/**

**/*.svg
**/*.sh

/public/*

如果让那个每个页面符合 prettier 在每个页面格式化就太麻烦了，那么我们就需要在 package.json设置一下。利用 prettier --write . 把我们当起所有文件格式化一次，不包过忽略文件里面的

"scripts": {
        "serve": "vue-cli-service serve",
        "build": "vue-cli-service build",
        "lint": "vue-cli-service lint",
        "prettier": "prettier --write ."
},

执行 npm run prettier 就会把当前项目所有文件都格式化成 prettier 设置的风格

三、使用ESLint检测

使用 Lint 工具或代码风格检测工具，则可以辅助编码规范执行，有效控制代码质量。EsLint 则是其中一个很好的工具。

• 语法错误校验
• 不重要或丢失的标点符号，如：分号;
• 未被使用的参数提醒
• 漏掉的结束符，如：花括号}
• 确保样式的统一规则，如 sass 或者 less
• 检查变量的命名
• 影响性能的代码提醒，如 v-if 和 v-for 同时使用

1、在前面创建项目的时候，我们就选择了ESLint，所以Vue会默认帮助我们配置需要的ESLint环境。 2、VSCode需要安装ESLint插件： 3、配置规范

有一个问题 ESLint 设置的一些规范可能会和 上面设置的 prettier 设置的规范会有冲突。不兼容

解决ESLint 和 Prettier 冲突 兼ESLint和Prettier

1、需要安装两个库

安装插件：vue在创建项目时，如果选择prettier，那么这两个插件会自动安装

npm i eslint-plugin-prettier eslint-config-prettier -D // 开发时依赖

2、添加prettier插件：

  extends: [
    "plugin:vue/vue3-essential",
    "eslint:recommended",
    "@vue/typescript/recommended",
    "@vue/prettier",
    "@vue/prettier/@typescript-eslint",
    'plugin:prettier/recommended'
  ],

• 更多配置

// @see: http://eslint.cn

module.exports = {
	root: true,
	env: {
		browser: true,
		node: true,
		es6: true
	},
	/* 指定如何解析语法 */
	parser: "vue-eslint-parser",
	/* 优先级低于 parse 的语法解析配置 */
	parserOptions: {
		parser: "@typescript-eslint/parser",
		ecmaVersion: 2020,
		sourceType: "module",
		jsxPragma: "React",
		ecmaFeatures: {
			jsx: true
		}
	},
	/* 继承某些已有的规则 */
	extends: ["plugin:vue/vue3-recommended", "plugin:@typescript-eslint/recommended", "prettier", "plugin:prettier/recommended"],
	/*
	 * "off" 或 0    ==>  关闭规则
	 * "warn" 或 1   ==>  打开的规则作为警告（不影响代码执行）
	 * "error" 或 2  ==>  规则作为一个错误（代码不能执行，界面报错）
	 */
	rules: {
		// eslint (http://eslint.cn/docs/rules)
		"no-var": "error", // 要求使用 let 或 const 而不是 var
		"no-multiple-empty-lines": ["error", { max: 1 }], // 不允许多个空行
		"no-use-before-define": "off", // 禁止在 函数/类/变量 定义之前使用它们
		"prefer-const": "off", // 此规则旨在标记使用 let 关键字声明但在初始分配后从未重新分配的变量，要求使用 const
		"no-irregular-whitespace": "off", // 禁止不规则的空白

		// typeScript (https://typescript-eslint.io/rules)
		"@typescript-eslint/no-unused-vars": "error", // 禁止定义未使用的变量
		"@typescript-eslint/no-inferrable-types": "off", // 可以轻松推断的显式类型可能会增加不必要的冗长
		"@typescript-eslint/no-namespace": "off", // 禁止使用自定义 TypeScript 模块和命名空间。
		"@typescript-eslint/no-explicit-any": "off", // 禁止使用 any 类型
		"@typescript-eslint/ban-ts-ignore": "off", // 禁止使用 @ts-ignore
		"@typescript-eslint/ban-types": "off", // 禁止使用特定类型
		"@typescript-eslint/explicit-function-return-type": "off", // 不允许对初始化为数字、字符串或布尔值的变量或参数进行显式类型声明
		"@typescript-eslint/no-var-requires": "off", // 不允许在 import 语句中使用 require 语句
		"@typescript-eslint/no-empty-function": "off", // 禁止空函数
		"@typescript-eslint/no-use-before-define": "off", // 禁止在变量定义之前使用它们
		"@typescript-eslint/ban-ts-comment": "off", // 禁止 @ts-<directive> 使用注释或要求在指令后进行描述
		"@typescript-eslint/no-non-null-assertion": "off", // 不允许使用后缀运算符的非空断言(!)
		"@typescript-eslint/explicit-module-boundary-types": "off", // 要求导出函数和类的公共类方法的显式返回和参数类型

		// vue (https://eslint.vuejs.org/rules)
		"vue/no-v-html": "off", // 禁止使用 v-html
		"vue/script-setup-uses-vars": "error", // 防止<script setup>使用的变量<template>被标记为未使用，此规则仅在启用该no-unused-vars规则时有效。
		"vue/v-slot-style": "error", // 强制执行 v-slot 指令样式
		"vue/no-mutating-props": "off", // 不允许组件 prop的改变（明天找原因）
		"vue/custom-event-name-casing": "off", // 为自定义事件名称强制使用特定大小写
		"vue/attributes-order": "off", // vue api使用顺序，强制执行属性顺序
		"vue/one-component-per-file": "off", // 强制每个组件都应该在自己的文件中
		"vue/html-closing-bracket-newline": "off", // 在标签的右括号之前要求或禁止换行
		"vue/max-attributes-per-line": "off", // 强制每行的最大属性数
		"vue/multiline-html-element-content-newline": "off", // 在多行元素的内容之前和之后需要换行符
		"vue/singleline-html-element-content-newline": "off", // 在单行元素的内容之前和之后需要换行符
		"vue/attribute-hyphenation": "off", // 对模板中的自定义组件强制执行属性命名样式
		"vue/require-default-prop": "off", // 此规则要求为每个 prop 为必填时，必须提供默认值
		"vue/multi-word-component-names": "off" // 要求组件名称始终为 “-” 链接的单词
	}
};

四、git代码提交规范

git Husky 和 ESLint

虽然我们已经要求项目使用eslint了，但是不能保证组员提交代码之前都将eslint中的问题解决掉了：

• 也就是我们希望保证代码仓库中的代码都是符合eslint规范的；
• 那么我们需要在执行 git commit 命令的时候对其进行校验，如果不符合eslint规范，那么自动通过规范进行修复；
  • 在 git commit 之前先做一次eslint规范检查，如果不符合就自动执行一个命令 eslint-fix 修复，修复完符合eslint规范之后，再把代码提交上去。
  • 那么我们就需要监听 git commit 对这个命令做一个拦截
• 那么如何做到这一点呢？可以通过Husky工具：

husky是一个git hook工具，可以帮助我们触发git提交的各个阶段：pre-commit、commit-msg、pre-push

pre-commit：commit 之前做一些操作

commit-msg：对提交的信息做一些检查，不符合提交信息规

pre-push：对push做一个拦截

安装husky相关的依赖：

这里我们可以使用自动配置命令：

npx husky-init && npm install

如果报错的话可能是不支持 && 分开执行就行

• 这里会自动加进来一个 "perpare": "husky install" 做拦截初始化操作

• 在项目目录下会自动生成 .husky 文件夹：

#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"

npm run lint

这样就可以在 提交代码之前 做一次格式化 通过 eslint 对代码做修复 保证提交到代码库里的代码是符合 eslint 规范

git commit -m "提交规范"

我们在提交代码的时候 git commit 最好是修改什么内容写什么修改信息。提交规范是很重要的，涉及到如果某天我们回退版本的时候就会变得非常重要，可以追踪回退版本的代码是谁改的，改的什么内容。这里最好是符合什么规范。如果提交的内容不规范，就不允许提交。

举个🌰

但是如果每次手动来编写这些是比较麻烦的事情，我们可以使用一个工具：Commitizen

Commitizen 是一个帮助我们编写规范 commit message 的工具；

1.安装Commitizen

npm install commitizen -D

2.安装cz-conventional-changelog，并且初始化cz-conventional-changelog：

npx commitizen init cz-conventional-changelog --save-dev --save-exact

这个命令会帮助我们安装cz-conventional-changelog：

并且在package.json中进行配置：

这个时候我们提交代码需要使用 npx cz：

• 第一步是选择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 | 代码回退 |

• 第二步选择本次修改的范围（作用域）

• 第三步选择提交的信息

• 第四步提交详细的描述信息

• 第五步是否是一次重大的更改

• 第六步是否影响某个未解决问题

如果我们按照cz来规范了提交风格，但是依然有同事通过 git commit 按照不规范的格式提交应该怎么办呢？

• 我们可以通过commitlint来限制提交；

1.安装 @commitlint/config-conventional 和 @commitlint/cli

npm i @commitlint/config-conventional @commitlint/cli -D

2.在根目录创建commitlint.config.js文件，配置commitlint

module.exports = {
  extends: ['@commitlint/config-conventional']
}

3.使用husky生成commit-msg文件，验证提交信息：

npx husky add .husky/commit-msg "npx --no-install commitlint --edit $1"

五、遇到的问题

1、npx husky add .husky ...... commitlint --edit "$1"' # 失效原因

• 如果你的电脑不是Mac，用的不是Linux的话，你执行下面的语句是无效的。
• 因为这条语句里包含着$1,它是在shell命令中代表的是参数。
• Windows系统的cmd是没有$1这种操作符。

npx husky add .husky/commit-msg 'npx --no-install commitlint --edit "$1"' 

• 当你在Windows系统下执行时，将是无效的

• 首先我们要搞明白这条命令做了什么事情:

1. 添加一个文件commit-msg
2. 然后再commit-msg中填充该npx指令

那么我们要怎么在Windows系统添加一个commit-msg文件呢，并且将命令填充到文件里。

解决

我们直接把步骤分开执行就可以解决

1. 添加一个文件commit-msg在.husky文件夹下, 执行下面命令

npx husky add .husky/commit-msg

因为我们没有用到shell命令符 上面的指令肯定能执行创建

2. 在创建后的文件夹commit-msg文件里直接填充你的指令即可

接着就可以测试你的git commit的提交不规范是否能被拦截啦

如上图，安装Vuex 结束后，提示npm audit fix

npm audit fix ：npm@6.1.0, 检测项目依赖中的漏洞并自动安装需要更新的有漏洞的依赖，而不必再自己进行跟踪和修复。

npm audit ： npm@5.10.0 & npm@6，允许开发人员分析复杂的代码，并查明特定的漏洞和缺陷。

最好不要管他，本人试过后 运行时会报错。如果大佬们有好的解决方法 评论区请指点一下

小结

本文简单介绍了基于Vue项目搭建规范、统一编码风格和git代码提交，解决了团队协作中不同代码风格对彼此造成的困扰与影响。以上就是本文全部内容，如果对你有帮助，可以随手点个赞。