前端规范我是这么建立的

由于之前一直是一个人负责业务开发，在前端规范上比较随意，后面意识到野路子一直这么下去永远成不了正规军，于是我开始规划整理了一套前端规范来强行约束自己，提前让自己能适应多人协同合作开发的大项目中，保持代码的整齐划一规范性。

代码规范

在工程里采用的方案是： Prettier + Eslint + Husky

Prettier

专门做代码格式化工具，美化代码格式包括缩进、换行、添加空格等，不提供语法方面的检测，语法侧可以结合下文中提到的Eslint, 它们各自做着自己擅长的事情。

① 安装依赖

shell 复制代码

  # --save-exact 的作用就是固定依赖包的版本，不要带 ^ 或 ~ ，避免出现小版本。 有利于版本统一。
  yarn add --dev --exact prettier

② 在项目根目录下配置.prettierrc.json（规范规则）、.prettierignore（忽略对应文件夹规范检测）文件。

json 复制代码

{
  "trailingComma": "all",
  "singleQuote": true,
  "printWidth": 120,
  "arrowParens": "always"
  // ...
}

③ IDE 中安装 Prettier-Code Formatter 插件，在 IDE 设置中找到 format on save 打开，就可以在代码保存时，自动格式化了

Eslint

Javascript 是一个动态的弱类型语言，没有预编译程序，所以开发者通常只能在执行过程中去调试代码。而 Eslint 的出现就可以帮助我们在编码过程中避免掉语法上的一些错误, 提高我们的代码质量，Eslint 也有格式化代码的能力（针对 JS/TS），不过没有 Prettier 这么全面, 所以我们这里采用的方案是检测语法错误交给 Eslint, 美化代码则通过继承 Prettier 的规则，以此完成代码测的全方位检测。

① 安装依赖

shell 复制代码

"eslint": "^8.53.0",
"eslint-webpack-plugin": "^4.0.1",

② 项目新增 .eslintrc.js 文件，命令如下：

shell 复制代码

yarn create @eslint/config

这里按照终端的提示一步步往下就会生成一份 .eslintrc.js 配置文件。

③ 结合 Prettier 使用

还需要安装eslint-plugin-prettier、eslint-config-prettier插件，并修改 .eslintrc.js 文件中的 extends 项：

shell 复制代码

# eslint-config-prettier： 使用 Prettier 默认推荐配置，并且关闭 eslint 自身的格式化功能，防止 Prettier 和 ESLint 的自动格式化的冲突
# eslint-plugin-prettier: 由 Prettier 生态提供，配置后才能在不符合 prettier 规范时报告错误给 ESLint，显示在警告台
yarn add eslint-plugin-prettier eslint-config-prettier

javascript 复制代码

extends: [
  'eslint:recommended',
  'plugin:@typescript-eslint/recommended',
+  'plugin:prettier/recommended'
],

④ Webpack 工程中全局配置 Eslint, 在编译期间完成代码检测的工作。

shell 复制代码

yarn add eslint-webpack-plugin --dev

然后在 webpack.config.js 配置文件中引入插件：

javascript 复制代码

const EslintWebpackPlugin = require('eslint-webpack-plugin');
// ...
module.exports = {
  plugins: [
    new HtmlWebpackPlugin({
      title: '管理输出',
      template: './index.html',
    }),
    new ProgressPlugin(true),
    new EslintWebpackPlugin(),
    // new BundleAnalyzerPlugin(),
  ],
}

⑤ 如果你的项目工程是基于 Vue 开发的，则可以用到 Vue 官方插件 eslint-plugin-vue。 hashkey 启动项目，代码中有如不符合规范的时候，观察控制台会警告。

格式化的时间节点

目前我在项目中采取的方案是通过在项目根目录建立 .vscode 文件夹，里面建立 settings.json 文件，这个可以作为项目独立配置，不影响其他项目。所以我在这里做了保存代码时自动化格式代码的操作。

json 复制代码

{
  "editor.formatOnSave": true,
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": true
  },
}

还有另一个方案：在 git commit 的阶段自动将提交的代码格式化，需要借助工具 husky, 可以帮助我们在 git 阶段提交消息、运行测试、检查代码。这个后续我会在实际项目工程做配置后，再将实际操作和使用感受更新到文章中。

Git commit 规范

为什么我会去做 git commit 提交记录的规范呢？因为我觉得一个好的信息提交记录，能帮助我们在协同开发中清晰的了解到每一次迭代的功能具体做了什么，方便回溯。我目前采用的是 Angular 规范 git 提交，message 格式如下：

arduino 复制代码

# <类型>[可选 范围]: <描述>
<type>[optional scope]: <description>

# [可选 正文]
[optional body]

# [可选 脚注]
[optional footer(s)]

范文的含义

Type 类型

feat：新功能（feature）
fix：修补bug
docs：文档（documentation）
style：格式（不影响代码运行的变动）
refactor：重构（即不是新增功能，也不是修改bug的代码变动）
test：增加测试
chore：构建过程或辅助工具的变动
rovert: 代码回退
build：变更项目构建或依赖外部

Scope

Scope 指本次 commit 提交影响的范围，可以根据项目划分不同的功能块。

Subject

commit 的简短描述

Body

commit 的详细描述

运用 Commitlint + Husky 工具约束提交规范

每次提交 commit 的时候，commitlint 可以检查我们的信息是否符合规范, 配合 husky 自动进行 commitlint 检查。

① 安装

shell 复制代码

yarn add @commitlint/config-conventional @commitlint/cli -D
yarn add husk -D

② 配置 comitlint 文件

shell 复制代码

echo "module.exports = { extends: ['@commitlint/config-conventional'] };" > commitlint.config.js

js 复制代码

module.exports = { 
  extends: ['@commitlint/config-conventional'],
  rules: {
    'type-enum': [2, 'always', ['fix', 'doc']]
  }
};

检测执行命令如下：

shell 复制代码

echo 'test: test commit' | npx commit lint

如果输入的信息与我们配置的规则不一致，则会看到控制台报错。

③ 配置 husky

给 commit 这个动作增加一个 hook，动作触发时自动执行 commitlint 检查。

shell 复制代码

# 生成 .husky 文件夹
npx husky install

在该文件夹下创建 commit-msg 文件，文件内容如下：

sh 复制代码

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

yarn commitlint

同时在 package.json 文件中新增脚步命令：

json 复制代码

{
  "scripts": {
+   "commitlint": "commitlint --config commitlint.config.js -e -V"
  }
}

配置完后，通过 git commit 提交不符合规范的信息时会报错：

shell 复制代码

$ commitlint --config commitlint.config.js -e -V
⧗   input: fox: change
✖   type must be one of [feat, fix, docs, style, refactor, perf, test, chore, revert, build] [type-enum]

✖   found 1 problems, 0 warnings

④ 过程中我遇到的问题

工程属于子工程下，.git 文件在 parent 中时，npx install husky 会报错

shell 复制代码

husky - .git can't be found

解决方案如下, 路径根据自己的项目来设置：

json 复制代码

{
  "scripts": {
+   "prepare": "cd ../../ && husky install webpack/demo/.husky",
  }
}

总结

在团队的协调合作开发中，一套标准规范也是能大大提高开发现率，减少沟通成本的。在这次前端规范探索的路上，我初步建立了一套规范严格来要求自己，我也开始感受到了标准给我自己带来的便捷，不过高标准的规范中远不止这些，后续也会再挖掘一些规范标准来实践，后续也会更新到文章中。

最后：欢迎大家指正出文章中说的不对或者做的不足地方，一定会及时更正、补足。

前端规范我是这么建立的: Prettier + Eslint + Husky

前端规范我是这么建立的

代码规范

Prettier

Eslint

格式化的时间节点

Git commit 规范

范文的含义

运用 Commitlint + Husky 工具约束提交规范

总结