社会上，需要靠一些法律和法规去约束一些行为。开发中也是如此。 如果单靠道德，那将毫无约束力，到最后，全凭良心和惯性。

约定的内容包括：html、图片、css、命名、js、vue、react等等。

🔍前言

➡️ 前端代码规范

→ 文档

1、京东凹凸

2、腾讯TGideas

3、腾讯alloyteam团队

4、百度

5、JavaScript Standard Style:Node.js、Express在用。

→ 工具

统一风格和代码质量：

1、ESLint 检测js语法和格式问题。 2、Prettier 自动处理代码，格式化为统一风格。

两者区别：eslint偏向于js语法的检测和格式的问题。prettier更侧重风格，比如说多个字符、使用单还是双引号。

执行脚本前，预处理被操作的对象：

1、 Husky 拦截工具 2、Lint-staged 官方说的：针对暂存的 git 文件运行 linter，不要让 💩 溜进您的代码库！（针对性地、范围性地、去处理范围内的文件。避免做到别人的东西去了，同时也加快脚本处理速度。）

git规则

1、Commitizen git commit 规范大家的commit message 2、Commitlint 检测commit message\

☕正文

环境准备：

• 1、nodejs、
• 2、国内npm镜像（淘宝）（国外慢）、
• 3、vscode
• 4、git

配国内镜像 npm config set registry https://registry.npmmirror.com/，这样下面创项目的时候才快些。

➡️ 脚手架创项目

→ 脚手架

• 1、cra(create react app)

npx create-react-app [项目名]

创ts项目在命令后面加--template typescript

• 2、vite

npm create vite@latest react-demo-vite

ts项目加--template react-ts

用哪个：vite快，cra久（稳）。大家可以自行选择。

➡️ 规则

→ eslint

去vscode插件扩展下个ESLint。

安装和配置ESLint：

npm init @eslint/config@latest

• 流程

1、eslint检查

选择这个👇： To check syntax and find problems 检查语法并发现问题

2、类型模块

选择这个👇： JavaScript modules(import/export)

---

JavaScript modules(import/export) 和 CommonJS(require/exports) 区别：前者是js模块（es modules）。后者是commonjs。

• es modules

这么用👇：

// 导出
export const myFunction = () => {...}

// 导入
import { myFunction } from './myModule'

1、用import和export去做导入和导出的。 2、支持异步加载。 3、每个模块都有自己的作用域，不污染全局作用域。 4、模块在编译时就确定了依赖关系。所以，支持静态分析。 5、可用<script type="module">去加载模块。

---

• commonjs

这么用👇：

// 导出
module.exports = { myFunction }; 

// 导入
const { myFunction } = require('./myModule');

1、用require和module.exports或exports去做导入和导出的。 2、不支持异步加载。 3、可能会污染全局作用域。 4、支持动态加载模块。 5、通常用于nodejs服务器端环境。

浏览器环境用es modules, nodejs环境用commonjs。这里react项目装eslint，用es modules。

3、选react项目

4、选ts

5、选browser

6、配置相关依赖关系：

• eslint@9.x
• globals
• @eslint/js
• typescript-eslint
• eslint-plugin-react

7、选安装工具

安装完成。

安装完后，react根目录会多一个eslint.config.mjs文件。

文件内容如下：

• 其他相关react、ts、eslint依赖

1、ts解析器：@typescript-eslint/parser 2、ts有关规则补充：@typescript-eslint/eslint-plugin 3、ts或js检测导入导出正确性和一致性检测插件：eslint-plugin-import 4、对js和ts代码的导入语句进行排序：eslint-plugin-simple-import-sort 5、检查在react中是否正确使用hooks：eslint-plugin-react-hooks

package.json：

eslint.config.mjs:

eslint9以上，要求扁平化（所有eslint配置信息放在一个文件中）ESLint配置文件。

1、就是eslint规则写在一个文件就够了。 2、不用分散到.eslintrc.js、.eslintrc.json、package.json或者其他文件中。 3、所有eslint的（规则啊、解析器选项啊、插件啊等等这些）写在eslint.config.js或者eslint.config.mjs中。 4、eslint.config.mjs比eslint.config.js多了一个m，表示是一个es模块。通过import和export导入导出。

安装完成之后，怎么检验eslint安装成功了没呢？ 我们就在App.tsx里面写个const a = '1' 然后就看，有没有红色波浪线，鼠标移上去有没有提示那些\

有时候安装完eslint好像项目文件里面不会报错（也就是没有生效），那怎么测试呢？ 办法就是直接去执行一下。 首先在package.json文件里面的scripts加个lint: " eslint 'src/**/*.+(js|ts|jsx|tsx)' "

然后在项目中执行一下npm run lint。报这种错就是说明咱们那个eslint.config.mjs是没有报错导致中断的，能正常走。如果不是，那就要检查一下eslint.config.mjs的代码哪里写错而导致eslint代码中断了。

---

→ prettier

第一步：下载vscode插件。

去vscode插件扩展下个Prettier - Code formatter。

第二步：命令行下载一些包。

再来，在刚刚下载的react项目的终端，安装以下一些包。

记住这些包全用-D下载到开发依赖下。 也就是说，这些包只在开发的时候用到，不会用到生产上线的包中。

npm install prettier -D npm install eslint-config-prettier -D npm install eslint-plugin-prettier -D

在eslint.config.mjs中配置：

装完这些，加上，配完这些，如何知道prettier是否真的配置到项目中去了呢？

来到App.tsx这里看:

这就说明配上了，Prettier代码风格已经在项目中生效了。

这样，咱们先去package.json里面写条命令。format: " prettier --write 'src/**/*.+(js|ts|jsx|tsx)' "。如下👇：

跑一跑npm run format。如下👇：

命令生效，没有错误红色波浪线报错了。Prettier风格格式化了整体的代码，使得代码风格统一。

哎，有的小伙伴可能就问了，Prettier的风格默认配置是啥？

官方文档中罗列出来了。

能自己团队中老大，自行自定义不？能，可以。

这样自己自行定义：

{
  "printWidth": 160, // 每行代码最大字符宽度是160，多了自动换行，太长可读性差。
  "tabWidth": 2, // 缩进的空格数为2。
  "useTabs": false, // 使用制表符缩进，而不是空格缩进。
  "singleQuote": true, // 用单引号替代双引号。
  "semi": false, // 语句末尾不加分号。
  "trailingComma": "none", // 对象的键值对，不允许尾随逗号。
  "arrowParens": "avoid", // 当箭头函数只有一个参数时，不要加括号。
  "bracketSpacing": true, // 大括号内要有空格，这样{ foo: bar }，而不是{foo:bar}这样。
  "singleAttributePerLine": false, // 不将jsx属性拆分成单独的行。
  "endOfLine": "auto" // 自行自动换行。
}

那这里呢，平常常用的自己的风格可以自行定义。

我平常的风格如下：

{
  "arrowParens": "avoid", // 箭头函数只有一个参的时候忽略括号
  "bracketSpacing": true, // 括号内不要出现空格
  "endOfLine": "lf", // 行结束使用Unix格式
  "jsxBracketSameLine": false, // 格式化JSX元素时不将大括号放在同一行，换行放
  "printWidth": 100, // 行宽
  "proseWrap": "preserve", // 换行方式
  "semi": false, // 分号
  "singleQuote": true, // 使用单引号
  "tabWidth": 2, // 缩进
  "useTabs": false, // 使用tab缩进
  "trailingComma": "es5", // 后置逗号，多行对象、数组最后一行加逗号
  "parser": "typescript" // 用ts解析器去解析ts 
}

---

→ .vscode

存放当前项目特定的vscode配置文件。

在根目录下创建一个文件夹.vscode。

文件夹里面创建一个文件setting.json。

• 自动保存修复

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

这个就是一保存文件，自动修复自动统一风格。

→ git

选云仓库。

• github
• coding
• gitlab
• ...

git remote add origin 远程仓库地址
git add .
git commit -m "init"
git push -u origin master

→ husky

git hook 钩子工具。

在git commit 之前做一些操作。

• ☝️第一步

安装: npm i -D husky

• ✌️第二步

init一下： npm husky init

多了这些内容：

根目录多了个.husky文件夹，文件夹里面有个文件pre-commit：

package.json中加了一条script命令: prepare: "husky"

git操作之前，会首先执行一下npm test这条命令。

我们改一下：

npm run format
npm run lint
git add .

比如这里我估计写错一个地方，来验证一下是不是确实运行了npm run format（也就是Prettier操作过了）：

跑完之后，自行就去执行了npm run format了。并commit了。

跑完之后呢，可以自行去git log去看看，看看是不是真的commit了。

→ commitlint

搞完git commit这个钩子的一些额外命令的执行外呢。

来做一下git commit message的统一。

comitlint文档地址

安装: npm install --save-dev @commitlint/{cli,config-conventional}

配置：echo "export default { extends: ['@commitlint/config-conventional'] };" > commitlint.config.js

向commit-msg钩子添加提交消息检测: echo "npx --no -- commitlint --edit \$1" > .husky/commit-msg

出这个错误，就是要把js改成mjs就可以了。前面有提到mjs和js，js moudle和commonjs的区别，改一下名字即可。

再重新执行一下git commit -m "111" message随便写的那种。

就是乱写不给过这样的。

要过就得规范写。要约束人，这样回头看commit message就比较好找。

规范东西怎么写：

'build', // 构建
'chore', // 杂货 零活 小工具
'ci', // 持续集成
'docs', // 文档
'feat', // 功能
'fix', // 修复bug
'perf', // 性能
'refactor', // 重构
'revert', // 重置 回退
'style', // 样式
'test', // 测试

所以，限制了乱写这种行为，正确命令行写法如下：

git commit -m "feat: 新增了某些功能" 。

🥤后记

通过约定去约束，加上约定文档和工具加持，甚至说code review过后得到至少一个approval才能继续代码合并。

当然，风格不一无可厚非，所以我们不洗脑别人不强制别人一定要统一一样的编程规范风格。但是，我们可以通过一些工具去处理成统一的风格，从而，使得多人开发项目中代码风格不割裂。

最后达成，虽然，各人习惯不同，但是，最终项目代码风格一致。

作用之处： 1、防代码杂乱 2、利于后期维护 3、利于新人接手

☎️ 希望对大家有所帮助，本文有些地方可能考虑不够周到，有些纰漏，就当抛砖引玉，还望您海涵，如有错误，望不吝赐教，欢迎评论区留言互相学习。感谢阅读，祝您开发有乐趣。