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

约定的内容包括：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/，这样下面创项目的时候才快些。

➡️ 脚手架创项目

→ 脚手架

npx create-react-app [项目名]

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

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。

这么用👇：

export const myFunction = () => {...}import { myFunction } from './myModule'

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

---

这么用👇：

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文件。

文件内容如下：

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,   "tabWidth": 2,   "useTabs": false,   "singleQuote": true,   "semi": false,   "trailingComma": "none",   "arrowParens": "avoid",   "bracketSpacing": true,   "singleAttributePerLine": false,   "endOfLine": "auto" }

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

我平常的风格如下：

{  "arrowParens": "avoid",   "bracketSpacing": true,   "endOfLine": "lf",   "jsxBracketSameLine": false,   "printWidth": 100,   "proseWrap": "preserve",   "semi": false,   "singleQuote": true,   "tabWidth": 2,   "useTabs": false,   "trailingComma": "es5",   "parser": "typescript" }

---

→ .vscode

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

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

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

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

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

→ git

选云仓库。

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

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 formatnpm run lintgit add .

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

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

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

搞完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', 'perf', 'refactor', 'revert', 'style', 'test', 

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

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

🥤后记

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

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

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

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

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