前端如何做好项目规范（一）本文主要介绍如何做好前端的项目规范，包含但不限于git提交规范，包管理器规范，命名的规范，代码

本文主要介绍如何做好前端的项目规范，包含但不限于git提交规范，包管理器规范，命名的规范，代码风格的统一等等。项目规范做的好，可以大大提升大家的工作效率，反之会严重影响工作效率。

项目规范做的不好的后果

我用 yarn 本地代码无法运行，用 npm 才可以正常运行。
我本地因为 node 版本原因，代码无法运行。
什么，你跑不起来？我这里是可以的呀。
eslint 与 prettier 规则互相冲突，裂开。
lint 规则形同虚设
流水线构建才发现代码 build error，开始慌了。
项目的 git 提交信息五花八门，完全看不懂每一个 commit 做了啥。
项目的命名规范（文件夹，文件，组件，变量，函数）五花八门，真乱呀。
代码风格不统一，改一行代码，结果整个文件风格全变，不利于 code review。
......
以上是我在日常工作中经常遇到的一些现象，由此可见项目规范的重要性

解决思路

我的理解其实就是用一些手段做好一致性，抹除差异性；提升开发效率与质量。

抹平大家的差异性（开发环境，个人编码风格等等）。
提升开发效率与质量（ts，eslint等等）。

如何做

统一包管理器的使用
目前的包管理器有 npm 、cnpm 、 yarn 、 pnpm 等，我们可以选择任何一种。但是在项目中我们必须统一包管理器，否则会有一些意想不到的问题。
为达到该目的，我们可以借助工具 only-allow 来统一项目使用的包管理器。在 package.json 中增加 preinstall 钩子即可
```
{
  "scripts": {
    "preinstall": "npx only-allow npm"
  }
}
```
限制node版本
利用 package.json 中 engines 字段设置 node 版本，搭配 engine-strict 来强制检查。

// package.json
{
    "engines": {
         "node": ">=16.0.0"
    },
}

.npmrc 文件设置 engine-strict=true

engine-strict=true

这样设置之后，其他人在安装依赖的时候，如果node版本不符合要求，就会报错。

git提交规范
约定式提交它提供了一组简单规则来创建清晰的提交历史。
我们可以使用 commitlint 来配置与校验 commit 信息。
- 如何配置
  使用各种各样的配置文件来进行配置，比如 commitlint.config.js 、.commitlintrc.js 等等。
- 配置规则
  这里是所有可配置的规则。
- 共享配置
  我们可以将我们的配置发布到 npm ，供他人使用；我们也可以使用社区他人提供的配置。比如 @commitlint/config-conventional， @commitlint/config-angular 等等。
- 我的配置方案
  安装依赖
```
npm install --save-dev @commitlint/config-conventional @commitlint/cli
```
  配置文件
```
// commitlint.config.js
module.exports = {
   extends: ["@commitlint/config-conventional"],
};
```
  如何检验commit是否符合我们的配置 commitlint -e
Change log
Change Log 是发布新版本时，用来说明与上一个版本差异的文档。
该功能对于一些提供基础能力的项目尤为重要，像 react，vue 等等都有自己的 Change Log 文档。
我们当然可以手动去维护该文档，每次发布新版本的时候，去补充对应的版本说明；但是这样太麻烦了，我们完全可以利用工具帮我们做到。
- 安装依赖
  npm install --save-dev conventional-changelog-cli
- 配置命令
```
{
  "scripts": {
    "changelog": "conventional-changelog -p angular -i CHANGELOG.md -s"
  }
}
```
生成的文件会包含版本，时间，以及对应的 commit 提交信息。
husky
husky 是一个 npm 包，它可以让我们使用 git 钩子变得非常简单。
- 安装依赖
  npm install husky --save-dev
- 启动husky
  npx husky install 该步骤完成之后，项目会多一个 .husky 的文件夹
- 配置 prepare
  上面的启动 husky 只是让我们自己本地生效，那么团队中的其他同学不启动的话，依然没有作用。所以我们需要在依赖安装的时候自动启动 husky，因此我们需要配置 prepare
```
// package.json 
{ 
  "scripts": { 
      "prepare": "husky install" 
  } 
}
```
- 配置git钩子
  比如我们可以在 commit-msg 阶段校验我们的 commit 信息是否符合规范；在 pre-commit 阶段校验代码格式等等。
- 配置 commit-msg 钩子
  npx husky add .husky/commit-msg "npx commitlint -e"

文章预告

后面会出第二篇文章，主要介绍如何利用 lint 工具做好项目规范，包含 eslint、prettier、stylelint、lint-staged等等

写在最后

本文主要介绍了如何做好项目规范，并给出了一些工具来帮我们去做好这个事情。至于工具的更多用法没有过多涉及，感兴趣的同学可以前往官网自行查看。工作中根据项目的不同，灵活使用这些工具来做好项目规范，提升开发效率与质量。

前端如何做好项目规范（一）

项目规范做的不好的后果

解决思路

如何做

更多好文

文章预告

写在最后