很少几个人协作开发的时候，可能代码格式和规范没那么重要，只要开发者水平不要差太多，相互口头说一下基本可以避免大部分问题。 但是团队人员一旦多起来，那么这种沟通成本就是几何级数增长了。这个时候就需要通过项目中的规范来实行了。 而这里面目前来说比较有效的办法就是通过 git钩子来对代码进行检查和格式化。
算了，项目开发时间比较紧迫，这里就做个简单的总结。 首先是husky7 + eslint +prettier + vue的相关代码检查开发依赖
"babel-eslint": "^10.1.0", "eslint": "^7.32.0", "eslint-config-prettier": "^8.3.0", "eslint-plugin-prettier": "^3.4.0", "eslint-plugin-vue": "^7.15.1", "husky": "^7.0.1", "lint-staged": "^11.1.2", "prettier": "^2.3.2",
安装依赖后，就是相关配置。
husky7的配置是通过工程化的方式，在项目目录下单独的 .husky 文件来简历对应的git钩子。
建议，在package.json中增加 script
"prepare": "husky install"
这样在安装依赖的时候，会自动执行husky的初始化
也可以手动，通过
npx husky install
来手动执行husky的初始化
然后添加提交的钩子
npx husky add pre-commit "npx lint-staged"
lint-staged对应的配置，需要在项目根目录新建 文件名为".lintstagedrc.json"的文件
内容如下：
{ "*.{js,vue}": ["eslint", "prettier --write"], "*.{less,scss}": "prettier --write", "*.{js,css,json,md}": ["prettier --write"] }
注意，扩展名列表中间不能有空格。前面代表要匹配的扩展名文件，后面代表对该文件执行的操作。
经过以上配置后，当被暂存的文件（git中staged的文件）,被commit时，就会对这些文件执行匹配规则，如果匹配到对应文件，则执行对应的命令。
例如按照以上配置，则
当被暂存的文件包含 js 或vue 扩展名的文件时，就会执行 eslint检查，并执行 prettier格式化，如果执行失败，git会给出提示并显示错误的文件及代码位置，按照要求修复文件再次提交即可。
如果执行成功，则将被自动提交(commit）。
对于vscode而言，会有部分prettier规则和 eslint规则不兼容的情况，主要表现在，缩进、结束标签匹配等。
下面是一些关键部分的eslint配置修改，用于匹配prettier的校验规则。
rules: { ‘max-len‘: [0, 150, 2, { ignoreUrls: true }], ‘vue/html-indent‘: [‘off‘, 2], ‘vue/html-closing-bracket-newline‘: [ 0, { singleline: ‘never‘, multiline: ‘always‘, }, ], // 未使用组件报错，禁用 ‘vue/no-unused-components‘: 0, // VUE模板未使用变量 ‘vue/no-unused-vars‘: 0, indent: [‘off‘, 2], ‘comma-dangle‘: [0, ‘always‘], semi: [2, ‘never‘] }
具体规则，可以根据实际使用情况，进行对应的开启关闭或者修改。
同时，建议使用 vscode，安装 vetur、vue-helper、prettier、ESLint、GitHistory、GitLens 插件辅助开发。