前端项目搭建规范的协同的配置

这篇主要写的是项目开发前的搭建规范，一些开发中用到的配置；让我们在组员协同开发项目时，减少不必要的冲突与代码风格与格式的紊乱；

代码的规范

1.1. 代码缩进格式化的集成editorconfig配置

一个项目的开发的往往是多人协同的产物，同个gitHub的地址上提交不同需求的分支，就可看出开发者的书写习惯，又或者是不同的开发工具（Visual studio Code/hbuilder/WebStorm等）的编码风格也不一致；这里的不同体现在代码缩进大小，空白符的配置，换行类型等…
针对上面的问题，这里介绍一个EditorConfig代码缩减格式化辅助工具；有助于在不同IDE编辑器上处理同一项目的多个开发人员维护一致的编码风格；
项目根目录下的配置示例文件.editorconfig

# http://editorconfig.org
root = true
[*] # 表示所有文件适用
charset = utf-8 # 设置文件字符集为 utf-8
indent_style = space # 缩进风格（tab | space）
indent_size = 2 # 缩进大小
end_of_line = lf # 控制换行类型(lf | cr | crlf)
trim_trailing_whitespace = true # 去除行首的任意空白字符
insert_final_newline = true # 始终在文件末尾插入一个新行

[*.md] # 表示仅 md 文件适用以下规则
max_line_length = off
trim_trailing_whitespace = false

而VScode编辑器需要安装一个插件：EditorConfig for VS Code

1.2. 使用prettier工具(格式化工具)

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

npm install prettier -D

2.配置文.prettier文件，在项目的根目录下

{
  "useTabs": false,
  "tabWidth": 2,
  "printWidth": 80,
  "singleQuote": true,
  "trailingComma": "none",
  "semi": false
}

键值的含义

• useTabs：使用tab缩进还是空格缩进，选择false；
• tabWidth：tab是空格的情况下，是几个空格，选择2个；
• printWidth：当行字符的长度，推荐80，也有人喜欢100或者120；
• singleQuote：使用单引号还是双引号，选择true，使用单引号；
• trailingComma：在多行输入的尾逗号是否添加，设置为 none；
• semi：语句末尾是否要加分号，默认值true，选择false表示不加；

3.创建.prettierignore忽略的文件

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

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

/public/*

4.VSCode需要安装prettier的插件

5.测试prettier的应用
测试一：书写单个文件时，直接保存即可格式化；
测试二：在package.json中配置scripts的命令；

"prettier": "prettier --write ."

运行npm run prettier，即可对整个项目文件进行格式化；

1.3. 使用ESLint检测

在项目中可使用ESLint代码格式化的转换，使用的方法有以下三种：
1.在项目的创建中，我们可进行选择ESLint，项目创建时会默认配置ESLint的环境；
2.VSCode需要安装ESLint的插件：

3.在项目中会出现eslint于prettier的冲突的问题，解放办法是：
(1). 安装插件 - （vue在创建项目时，如选择prettier，那这俩个插件会自动安装）
typescript npm i eslint-plugin-prettier eslint-config-prettier -D
(2). 添加prettier插件：'plugin:prettier/recommended'

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

1.4. git Husky和eslint

项目运用git管理的时，虽然开发进行eslint规范，但也不能保证组员提交代码之前将所有的代码中的问题都解决掉；这就提出了一个问题，怎么保证git仓库中的代码都是符合eslint的规范？
我们想到的是在组员执行git commit ''命令的时候对其进行校验，如不符合eslint规范，就自动通过规范进行修复；
以上的问题，可以通过Husky的工具来实现；Husky是一个git hook工具，可以帮助我们触发git提交的各个阶段：pre-commit、commit-msg、pre-push；那么如何使用husky呢？
这里我们可以使用自动配置命令：

npx husky-init && npm install

这里会做三件事：
1.安装husky相关的依赖：

2.在项目目录下创建 .husky 文件夹：
运行指令会自动创建.husky文件

npx huksy install

生成项目中的根目录文件

3.在package.json中添加一个脚本：
shell "prepare": "husky install", 的指令是预备的意思；执行上方的指令，会自动添加到package.json文件中；

接下来，我们需要去完成一个操作：在进行commit时，执行lint脚本：

这个时候当我们提交代码执行commit时会自动对代码进行linit校验；

1.5. git commit规范

1.5.1. 代码提交风格

在项目的开发中，不仅代码的书写有规范，提交的也可按照统一的分格提交内容；使得每次提交的版本内容与注解更加清晰；
那么在代码提交的git commit中怎么制定规范呢？在如下的提交分支中有不同的提交修改进行commit的说明:

但是对于以上的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文件中进行配置：
   

3. 使用Commitizen进行代码提交；示例提交语句：style(login): 'login style'
   执行 npx cz：
   第一步：选择type，本次更新的类型；即示例提交中的style
   
   注：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	代码回退

   第二步：选择本次修改的范围（作用域，括号中所声明的文件夹名称或模块）；即示例提交中的login
   
   第三步：书写提交代码的注解；即示例提交中的login style
   (max 86 chars):是不能超过86个字符
   
   第四步：提交详细的描述信息，可直接回车enter跳过此步骤；
   
   第五步：是否是一次重大的更改；可直接回车，或者选择no；
   第六步：是否影响某个open issue;一般用于开源项目，可直接回车跳过
   
   我们也可以在scripts中构建一个命令来执行 cz；使用指令npm run commit进行提交
   

1.5.2. 代码提交验证

虽然在1.5.1中增加了代码提交风格的使用，但是我们还是无法阻止组员使用git commit ‘****’的模式提交更改；这个时候我们就需要对代码提交进行验证来加于限制；这里介绍一个提交限制的工具：commitlint
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"