前端工程化中的代码规范和commit规范_统一规范的代码风格在前端工程化中-CSDN博客

本文链接：https://blog.csdn.net/Zhuang_Allen/article/details/105763155

当我们编写代码的时候，由于任务时间紧，任务量重，需求不明确等等，会导致每个人的代码可能五花八门，潇洒不羁，可是当团队协作或者同事交接的过程中就会出现灾难性的，过多的争论和多余的解释，最后难免走上重构的道路。因此我们需要统一风格，不仅可以减少出 bug 的几率，而且能增加代码的可读性。

代码规范

对前端而言，通常我们会使用ESLint+Prettier来统一前端代码规范和美化代码风格

1. 插件介绍
首先，对应ESLint大多都很熟悉，用来进行代码的校验
Prettier 直译过来就是"更漂亮的"，是一个能够完全统一你和同事代码风格的神器，对于刚开始没有协同的同事或者是后台同事转前端代码，相信你是看不懂的，也不可能一行一行去修改代码风格，这时候你应该想到Prettier，可以让你节省出时间来写更多的bug（不对，是修更多的bug），并且统一的代码风格能保证代码的可读性。

2. 实践出结果
（1）安装和配置Eslint

npm install eslint --save-dev 或 npm install eslint --save -g 进行全局安装

在项目根目录下新建文件.eslintrc并配置内容即可:
ps:了解更多配置，请查阅官网文档：https://eslint.bootcss.com/

module.exports = {
  root: true,
  parserOptions: {
    parser: 'babel-eslint'
  },
  env: {
    browser: true,
    es6: true
  },
  extends: [
    // https://github.com/standard/standard/blob/master/docs/RULES-en.md
    'standard',
    // https://github.com/vuejs/eslint-plugin-vue#priority-a-essential-error-prevention
    // consider switching to `plugin:vue/strongly-recommended` or `plugin:vue/recommended` for stricter rules.
    'plugin:vue/essential',
    "plugin:prettier/recommended",
  ],
  // required to lint *.vue files
  plugins: [
    'vue'
  ],
  // add your custom rules here
  rules: {
    "prettier/prettier": "error",
    // allow async-await
    'generator-star-spacing': 'off',
    // allow debugger during development
    'no-debugger': process.env.NODE_ENV === 'production' ? 'error' : 'off'
  }
}

(2) ESLint 与 Prettier配合使用
安装和配置Prettier插件

npm install prettier --save-dev
npm install eslint-plugin-prettier --save-dev

根目录创建.prettierrc 文件，能够写入YML、JSON的配置格式，并且支持.yaml/.yml/.json/.js后缀；

{
	"printWidth": 80,
	"tabWidth": 2,
	"useTabs": true,
	"singleQuote": true,
	"semi": true,
	"trailingComma": "all",
	"bracketSpacing": true
}

VS Code 编辑器
安装插件：ESlint，Prettier，VS Code 插件配置统一在 preference setting user setting 设置 (快捷键： Command + ,)，即可实现保存时自动格式化：

commit 规范

ESLint 与 Prettier确保我们把代码写的规范整理，可是总有漏网之鱼，当我们没有把eslint的错误提示修改完全，进而上传到git代码管理的话，那就麻烦大了，因此commit规范是eslint的最后一道屏障，当你提交的时候，如果错误提示没有修改完成或者代码没有统一风格，commit规范都是一一提示出来。
husky和lint-staged安装配置

npm install husky --save-dev
npm install lint-staged --save-dev

package.json下面配置

	"husky": {
		"hooks": {
			"pre-commit": "lint-staged",
			"commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
		}
	},
	"lint-staged": {
		"{src,build,config}/**/*.{js,json,vue}": [
			"eslint --fix",
			"git add"
		],
		"src/style/**/*.scss": [
			"prettier --write",
			"git add"
		]
	},

项目根目录下新建.commitlintrc.js，规则配置如下

const chalk = require('chalk');
const message = process.env['HUSKY_GIT_PARAMS'];
const fs = require('fs');

const scopes = ['BAAS-*']; // 可以是好多种 scopes // test

function parseMessage(message) {
	const PATTERN = /^(\w+)(?:\(([^)]+)\))?\: (.+)$/;
	const match = PATTERN.exec(message);
	if (!match) {
		return null;
	}
	return {
		type: match[1] || null,
		scope: match[2] || null,
	};
}

function getScopesRule() {
	const messages = fs.readFileSync(message, { encoding: 'utf-8' });
	const parsed = parseMessage(messages.split('\n')[0]);

	console.log(`${chalk.red.bgBlueBright(' COMMIT MESSAGE HEAD ')}`, parsed);

	if (!parsed) {
		return [2, 'always', scopes];
	}
	const { scope, type } = parsed;
	if (
		scope &&
		!scopes.includes(scope) &&
		type !== 'release' &&
		!/BAAS-.\d+/.test(scope)
	) {
		return [2, 'always', scopes];
	} else {
		return [2, 'always', []];
	}
}

module.exports = {
	extends: ['@commitlint/config-conventional'],
	rules: {
		'type-empty': [2, 'never'],
		'type-enum': [
			2,
			'always',
			[
				'chore', // 管理各种依赖包，库，例如：安装，卸载，重装，升级
				'docs', // 文档更新
				'feat', // 新功能
				'bug', // bug 处理
				'refactor', // 重构，包括结构，逻辑，样式
				'style', // 样式处理
				'test', // 本地测试
			],
		],
		'type-case': [2, 'always', 'lower-case'],
		'scope-empty': [2, 'never'],
		'scope-enum': getScopesRule,
		'scope-case': [2, 'always', 'upper-case'],
		'subject-empty': [2, 'never'],
		'subject-full-stop': [2, 'never', '.'],
		'subject-case': [0, 'never'],
		'header-max-length': [2, 'always', 144],
	},
};