从 0-1 构建 vue3 + pina 项目模版，以及代码规范配置。

安装

使用 vue 官方安装命令。

这一指令将会安装并执行 create-vue，它是 Vue 官方的项目脚手架工具。

# npm init vue@latest

这里我们没有选择安装 Eslint 和 Prettier。

代码规范

editorconfig

EditorConfig 有助于为不同 IDE 编辑器上处理同一项目的 多个开发人员维护一致的编码风格。

1.安装插件：EditorConfig for VS Code

2.在项目根目录下面新建文件命名为 .editorconfig，并增加以下配置

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

ESLint

ESLint是一个针对JS的代码风格检查工具，当不满足其要求的风格时，会给予 警告 或 错误。

民间中文网：eslint.bootcss.com/

安装

ESLint通常配合编辑器使用。

在vscode中安装ESLint

该工具会自动检查工程中的JS文件。

配置 settings.json

{
  // 每次保存的时候将代码按格式进行修复
  "editor.formatOnSave": true,
  "editor.codeActionsOnSave": {
    "source.fixAll": true
  },
  "eslint.validate": [
    "javascript",
    "vue"
  ]
}

安装eslint 库

检查的工作交给eslint库，如果当前工程没有，则会去全局库中查找，如果都没有，则无法完成检查。

检查的依据是eslint的配置文件.eslintrc。

# npm i -D eslint

创建 配置文件

这里我们选择的是 standard 风格的代码规范。

# npx eslint --init

rules 自定义的规则配置

no-console 配置为 error 。

  rules: {
    'no-console': 'error'
  }

no-console 配置为 warn 。

  rules: {
    'no-console': 'warn'
  }

注意

配置文件识别优先级

.eslintrc.js > .eslintrc.yaml > .eslintrc.yml > .eslintrc.json > .eslintrc > package.json。

如果找不到工程中的配置文件，也无法完成检查。

配置详解

env 配置代码的运行环境
parserOptions 该配置指定eslint对哪些语法的支持。

ecmaVersion: 支持的ES语法版本
sourceType
- script：传统脚本
- module：模块化脚本

parser

eslint的工作原理是先将代码进行解析，然后按照规则进行分析。

eslint 默认使用Espree作为其解析器，你可以在配置文件中指定一个不同的解析器。

globals

配置可以使用的额外的全局变量。

{
  "globals": {
    "var1": "readonly",
    "var2": "writable"
  }
}

eslint支持注释形式的配置，在代码中使用下面的注释也可以完成配置。

/* global var1, var2 */
/* global var3:writable, var4:writable */

extends

该配置继承自哪里。

它的值可以是字符串或者数组。

比如：

{
  "extends": "eslint:recommended"
}

表示，该配置缺失的位置，使用eslint推荐的规则。

rules

eslint规则集。

每条规则影响某个方面的代码风格。

每条规则都有下面几个取值：

off 或 0 或 false: 关闭该规则的检查
warn 或 1 或 true：警告，不会导致程序退出
error 或 2：错误，当被触发的时候，程序会退出

除了在配置文件中使用规则外，还可以在注释中使用：

/* eslint eqeqeq: "off", curly: "error" */

eslint.bootcss.com/docs/rules/

.eslintignore 配置文件

排除掉某些不需要验证的文件。

dist/**/*.js
node_modules

总结

以上 settings.json 和 .eslintrc.js 配置可以在代码保存的时候按照 ESLint 风格进行格式化，以及代码校验。

Prettier(可选）

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

在保存时，可以让代码直接符合 ESLint 标准（需要通过一些简单配置）。

安装

vscode 安装 prettier

配置 settings.json

{
  "editor.formatOnSave": true,
  "editor.codeActionsOnSave": {
    "source.fixAll": true
  },
  "eslint.validate": ["javascript", "vue"],
  "[javascript]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "[vue]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "[jsonc]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "[html]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "[css]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  }
}

安装 prettier

# npm install prettier -D

新建 .prettierrc 配置文件

{
  // 不尾随分号
  "semi": false,
  // 使用单引号
  "singleQuote": true,
  // 多行逗号分割的语法中，最后一行不加逗号
  "trailingComma": "none"
}

创建 .prettierignore 忽略文件

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

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

/public/*

总结

以上的 setting.json 和 .prettierrc 配置，保存的时候，就会使用 prettier 来格式化代码，使其符合 ESLint 的校验规则。

而无需我们手动进行更改了。

Git提交规范

约定式提交

<类型>[可选 范围]: <描述>

[可选 正文]

[可选 脚注]

也就是说，如果要按照 约定式提交规范 来去做的化，那么你的一次提交描述应该式这个样子的：

Commitizen助你规范化提交代码

commitizen 仓库名为 cz-cli ，它提供了一个 git cz 的指令用于代替 git commit，简单一句话介绍它：

当你使用 commitizen 进行代码提交（git commit）时，commitizen 会提交你在提交时填写所有必需的提交字段！

全局安装Commitizen

# npm install -g commitizen@4.2.4

安装并配置 cz-customizable 插件

使用 npm 下载 cz-customizable

# npm i cz-customizable@6.3.0 --save-dev

添加以下配置到 package.json 中

...
  "config": {
    "commitizen": {
      "path": "node_modules/cz-customizable"
    }
  }

项目根目录下创建 .cz-config.js 自定义提示文件

module.exports = {
  // 可选类型
  types: [
    { value: 'feat', name: 'feat:     新功能' },
    { value: 'fix', name: 'fix:      修复' },
    { value: 'docs', name: 'docs:     文档变更' },
    { value: 'style', name: 'style:    代码格式(不影响代码运行的变动)' },
    {
      value: 'refactor',
      name: 'refactor: 重构(既不是增加feature，也不是修复bug)'
    },
    { value: 'perf', name: 'perf:     性能优化' },
    { value: 'test', name: 'test:     增加测试' },
    { value: 'chore', name: 'chore:    构建过程或辅助工具的变动' },
    { value: 'revert', name: 'revert:   回退' },
    { value: 'build', name: 'build:    打包' }
  ],
  // 消息步骤
  messages: {
    type: '请选择提交类型:',
    customScope: '请输入修改范围(可选):',
    subject: '请简要描述提交(必填):',
    body: '请输入详细描述(可选):',
    footer: '请输入要关闭的issue(可选):',
    confirmCommit: '确认使用以上信息提交？(y/n/e/h)'
  },
  // 跳过问题
  skipQuestions: ['body', 'footer'],
  // subject文字长度默认是72
  subjectLimit: 72
}

使用 git cz 代替 git commit 使用 git cz 代替 git commit，即可看到提示内容

那么到这里我们就已经可以使用git cz 来代替了 git commit 实现了规范化的提交诉求了，但是当前依然存在着一个问题，那就是我们必须要通过 git cz 指令才可以完成规范化提交！

Hooks

先来明确一下我们最终要实现的效果？

我们希望，当《提交描述信息》不符合约定式提交规范的时候，阻止当前的提交，并抛出对应的错误提示。

Git hooks（git 钩子 || git 回调方法）

也就是：git 在执行某个事件之前或之后进行一些其他额外的操作

而我们所期望的 阻止不合规的提交消息，那么就需要使用到 hooks 的钩子函数。

详细的 HOOKS介绍 可点击这里查看
整体的 hooks 非常多，当时我们其中用的比较多的其实只有两个：

Git Hook	调用时机	说明
pre-commit	`git commit`执行前它不接受任何参数，并且在获取提交日志消息并进行提交之前被调用。脚本`git commit`以非零状态退出会导致命令在创建提交之前中止。	可以用`git commit --no-verify`绕过
commit-msg	`git commit`执行前可用于将消息规范化为某种项目标准格式。还可用于在检查消息文件后拒绝提交。	可以用`git commit --no-verify`绕过

commit-msg：可以用来规范化标准格式，并且可以按需指定是否要拒绝本次提交
pre-commit：会在提交前被调用，并且可以按需指定是否要拒绝本次提交

husky + commitlint

husky + commitlint 检查 提交描述 是否符合规范要求。

注意：npm 需要在 7.x 以上版本！！！！！

commitlint：用于检查提交信息

安装

# npm install --save-dev @commitlint/config-conventional@12.1.4 @commitlint/cli@12.1.4

创建 commitlint.config.js 文件
打开 commitlint.config.js ，增加配置项（ config-conventional 默认配置点击可查看）：

module.exports = {
  // 继承的规则
  extends: ['@commitlint/config-conventional'],
  // 定义规则类型
  rules: {
    // type 类型定义，表示 git 提交的 type 必须在以下类型范围内
    'type-enum': [
      2,
      'always',
      [
        'feat', // 新功能 feature
        'fix', // 修复 bug
        'docs', // 文档注释
        'style', // 代码格式(不影响代码运行的变动)
        'refactor', // 重构(既不增加新功能，也不是修复bug)
        'perf', // 性能优化
        'test', // 增加测试
        'chore', // 构建过程或辅助工具的变动
        'revert', // 回退
        'build' // 打包
      ]
    ],
    // subject 大小写不做校验
    'subject-case': [0]
  }
}

注意：确保保存为 UTF-8 的编码格式，否则可能会出现以下错误：

husky：是git hooks工具

安装

# npm install husky@7.0.1 --save-dev

启动 hooks ，生成 .husky 文件夹

# npx husky install

在 package.json 中新增 prepare 指令

  "scripts": {
    "prepare": "husky install"
  },

执行 prepare 指令：npm run prepare

添加 commitlint 的 hook 到 husky中，并指令在 commit-msg 的 hooks 下执行 npx --no-install commitlint --edit "$1" 指令

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

此时的 .husky 的文件结构。

总结

那么至此，我们就已经可以处理好了 强制规范化的git提交要求，到现在 不符合规范的提交信息，将不可在被提交！

pre-commit 检测提交时代码规范

我们期望通过 husky 监测 pre-commit 钩子，在该钩子下执行 npx eslint --ext .js,.vue src 指令来去进行相关检测：

添加 pre-commit

执行

# npx husky add .husky/pre-commit "npx eslint --ext .js,.vue src"

添加 commit 时的 hook（npx eslint --ext .js,.vue src 会在执行到该 hook 时运行），该操作会生成对应文件 pre-commit。

测试提交代码检测

关闭 VSCode 的自动保存操作
修改一处代码，使其不符合 ESLint 校验规则
执行 提交操作 会发现，抛出一系列的错误，代码无法提交

想要提交代码，必须处理完成所有的错误信息

lint-staged 自动修复格式错误【可选】

问题

在上一步 pre-commit 中，我们处理了 检测代码的提交规范问题，当我们进行代码提交时，会检测所有的代码格式规范 。

但是这样会存在两个问题：

我们只修改了个别的文件，没有必要检测所有的文件代码格式
它只能给我们提示出对应的错误，我们还需要手动的进行代码修改

想要处理这两个问题，就需要使用另外一个插件 lint-staged ！

lint-staged 自动修复

lint-staged 可以让你当前的代码检查 只检查本次修改更新的代码，并在出现错误的时候，自动修复并且推送。

安装

# npm i -D lint-staged

修改 package.json 配置

"lint-staged": {
    "src/**/*.{js,vue}": [
      "eslint --fix",
      "git add"
    ]
  }

如上配置，每次它只会在你本地 commit 之前，校验你提交的内容是否符合你本地配置的 eslint规则(这个见文档 ESLint )，校验会出现两种结果：

如果符合规则：则会提交成功。
如果不符合规则：它会自动执行 eslint --fix 尝试帮你自动修复，如果修复成功则会帮你把修复好的代码提交，如果失败，则会提示你错误，让你修好这个错误之后才能允许你提交代码。

修改 .husky/pre-commit 文件

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

npx lint-staged

再次执行提交代码
发现 暂存区中 不符合 ESlint 的内容，被自动修复

模版

gitee.com/panthers/vu…

【vue】EditorConfig + ESLint + Prettier + Git

安装