我是如何规范自己项目的开发流程

背景

总结一下自己学到的关于前端开发规范流程的搭建，

代码规范

ESLint

根据官网的命令安装和配置 ESLint

npm init @eslint/config

完成所有配置之后，ESLint会帮助我们创建.eslintrc.js，这里是因为我们配置文件的格式选择了JavaScript。（具体参数选择可根据项目需求，高亮仅供参考。

module.exports = {
    env: {
        browser: true,
        es2021: true,
    },
    extends: [       //继承一些规则集合
        "eslint:recommended", 
        "plugin:@typescript-eslint/recommended"
    ],
    overrides: [],
    parser: "@typescript-eslint/parser",   //解析器
    parserOptions: {   //解析器的配置
        ecmaVersion: "latest",   //JS版本：最新
        sourceType: "module",
    },
    plugins: ["@typescript-eslint"],   //一些规则合集
    rules: {},   //具体规则
};

因为我们第一步的选择是将代码规范交给ESLint，所以代码风格的处理将会使用Prettier

Prettier

一、安装依赖

yarn add prettier -D

二、创建.prettierrc.json配置文件。 （这里为了方便写注释使用的.js文件，具体配置项可去官网查看

module.exports = {
    printWidth: 120, // 一行代码的最大字符数
    tabWidth: 4, // 水平缩进的空格数
    useTabs: true, // 是否使用tab来缩进
    singleQuote: true, // 用单引号
    semi: true, // 结尾是否添加分号
    trailingComma: 'none', // 最后一个对象元素加逗号
    bracketSpacing: false // 对象里面的key和value值和括号间的空格
};

解决Prettier与ESLint的配置冲突

一、安装相关依赖

yarn add eslint-config-prettier eslint-plugin-prettier -D

eslint-plugin-prettier:先使用Prettier对代码进行格式化，再并对不一致的地方进行标记；

eslint-config-prettier:关闭所有不必要的或可能与Prettier冲突的规则。

二、接下来就是对.eslintrc.js进行修改

module.exports = {
    env: {
        browser: true,
        es2021: true,
+       node: true
    },
    extends: [
        'eslint:recommended',
        'plugin:@typescript-eslint/recommended',
+       'plugin:prettier/recommended'
    ],
    overrides: [],
    parser: '@typescript-eslint/parser',
    parserOptions: {
        ecmaVersion: 'latest',
        sourceType: 'module'
    },
    plugins: ['@typescript-eslint'],
    rules: {}
};

保存自动格式化

如果你使用的是vscode，那么在设置中搜索格式化，如果所示勾选，便可以在保存的时候自动格式化代码。（当然也可以在commit阶段统一进行处理

注意：这里需要安装Prettier插件

commit规范

在代码提交的时候，对代码进行检查，修复以及规则校验。

Husky

husky简单来说就是就是在git执行一些操作的时候触发一些钩子,在钩子处执行一些自己需要的命令。

一、安装依赖

yarn add husky -D

二、编辑package.json>prepare脚本并运行一次：

npm pkg set scripts.prepare="husky install" 
npm run prepare

对应的package.json中会新增

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

该命令会在npm install的时候自动执行，别人克隆完项目安装依赖时便会自动安装husky,运行完该脚本会在跟目录生成.husky文件

三、添加pre-commit钩子（提交信息前运行，可检查暂存区的代码

npx husky add .husky/pre-commit "npx lint-staged"

对应新增文件pre-commit

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

npx lint-staged

这里代码的意思会在pre-commit勾子触发的时候执行npx lint-staged

lint-staged

如果每次在git commit之后去检查所有文件是很不合理的，如果项目庞大，这将是一次很耗时的操作，lint-staged的作用就是只对暂存区的代码进行检验

安装：

yarn add lint-staged -D

在package.json中新增 （具体文件和规则可自行配置

{
    "lint-staged": {
        "*.{md,html,less,css,scss,json}": [
            "prettier --write"
        ],
        "*.{js,jsx,ts,tsx}": [
            "eslint --fix"
        ]
    },
}

以上就是所有在提交之前代码的规范和处理了，接下来就是规范git commit提交信息了

commitlint

一、安装：

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

二、添加配置项

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

三、添加commit-msg钩子

npx husky add .husky/commit-msg "npx --no-install commitlint -e $HUSKY_GIT_PARAMS"

配置完成之后，如果不按规则提交commit信息将会报错。如下

这里提示我们subject为空、type为空。必须按照conventional规则集来描述

提交类型: 摘要描述
<type>: <subject>

常见的type类型如下：（具体可参考commitlint

• feat：添加新功能
• fix：修复bug
• chore：一些不影响功能的更改
• docs：专指文档的修改
• pref：性能方面的优化
• refactor：代码重构
• test：添加测试代码

commitizen

如果觉得每次输入对应的type很麻烦，commitizen提供了终端可视化选择的方案，如下图所示：

关于终端可视化可以看下我的另一篇文章：《如何在自己的项目中实现脚手架的命令行交互》

安装：

yarn add 

在package.json中新增与commitlint一样的规则

{
    "config": {
        "commitizen": {
            "path": "cz-conventional-changelog"
        }
    },
}