前端代码规范工程化实践指南

现代前端技术飞速发展，前端已进入了以效率和质量为核心的工程化时代，各种自动化 工具 和技术的使用大大提高了开发效率。在团队协作中，编码规范至关重要，统一的编码规范可以降低代码维护的成本，但是，纯手工检查代码规范费时费力且难以保证准确性，因此，针对代码规范的自动化工具应运而生，从最早的JSLint，到JSHint，再到今天的ESLint，代码规范工具变得越来越成熟。再结合WebStorm、VSCode等编辑器可以在编写代码的时候自动提醒错误，在开发阶段就避免错误，提高开发效率。本文主要讨论前端工程化在代码规范上的一些实践。

ESLint

ESLint是当前最流行的代码规范检查工具，随着ECMAScript版本一直更新，通过配置检查规则来对代码进行规范检查，具有丰富的插件生态，也可以使用已有的规范以及进行自定义规则，可以满足大部分团队的需求。

下面介绍在react项目中如何使用ESLint。

首先，使用webpack搭建一个react的项目，在此不对具体搭建过程做具体介绍，然后使用npm安装eslint：

在项目根目录下新建.eslintrc文件，用于配置eslint进行代码规范检查的规则，下面是用于react项目的基本配置示例：

其中，parser用于指定eslint用来解析代码的解析器，babel-eslint是一个用于兼容ESLint的babel解析器的封装。env用于配置预定义的环境变量，此处指定了浏览器和Node.js以及ES6语法中所有的环境变量。parserOptions用于想要支持的Javascript语言选项，此处指定了ecmaVersion和sourceType，分别表示启用ES6语法以及ECMAScript模块。extends用于当前配置继承何种规范，此处，使用airbnb公司开源的eslint-config-airbnb规范， eslint-config-airbnb规范默认包含了ES6+的语法以及React的语法，它依赖于eslint、eslint-plugin-import、eslint-plugin-react以及eslint-plugin-jsx-i11y等npm包，安装时需要一起安装。 使用npm5+的版本安装eslint-config-airbnb：

rules即是配置的一系列规则，如果你不想使用airbnb中的某项规范，你可以在rules进行配置。下面列举示例：

“semi”和“quotes”是ESLint中规则的名称，第一个词是错误级别，可以使用下面的值之一：

"off" or 0 ：关闭规则;

"warn" or 1 ：将规则视为一个警告（不会影响退出码）;

"error" or 2 ：将规则视为一个错误 (退出码为1);

也可以写成如下的形式：

除了继承，你还可以使用第三方插件来配置规则，通过plugins来配置需要的插件列表，以eslint-plugin-react为例，配置如下：

配置完成后，我们希望能在每次修改代码后再次编译之前，能够对代码进行自动检查，先安装eslint-loader：

增加Webpack配置：

Webpack使用babel-loader解析React的代码，增加eslint-loader的配置，enforce设置为pre可以让Webpack在使用babel编译之前运行eslint进行代码检查。

eslint还提供了自动修复代码错误的能力，执行以下命令：

eslint会自动修复代码中的问题，但不是所有的问题都能被修复，剩余未被修复的问题会列出。

ESLint还可以结合编辑器进行使用，首先保证使用了npm安装了eslint以及生成了.eslintrc配置文件，以WebStorm编辑器为例， 配置：

File -> Settings Languages & Frameworks -> Javascript -> Code Quality Tools -> ESLint

勾选Enable即可。WebStorm就会在编写代码的时候进行提示，如果不符合ESLint规则则会进行颜色标注，让你更早发现代码问题。 VSCode需要安装eslint插件才能对代码进行提示，在此不做赘述。

EditorConfig

不同的操作系统和编辑器对于文本的格式的支持会有一定的区别，如果不统一一些规范，可能在团队协作的时候每次更新下来别人的代码就会一大堆报错。 EditorConfig是一种多编辑器插件，用于帮助开发者在不同的操作系统、编辑器和IDE之间定义和维护统一的代码风格。EditorConfig包含一个用于定义代码风格的配置文件和对应的编辑器插件，编辑器插件可以读取配置文件并对代码进行格式化。 EditorConfig的配置文件是.editorconfig，通常放置在项目根目录下。EdtorConfig插件对在文件夹的每一级目录下查找.editorconfig文件，直到查找到.editorconfig中包含root=true。 下面是一份.editorconfig配置文件：（注意：不是每种插件都支持下列所有属性）

root为true表示是最顶层的配置文件， [*]用于匹配需要格式化的代码，charset指定编码格式为utf-8,intent_ style指定缩进风格为空格，还可以选择tab，indent_ size用于指定缩进的列数，end_ of_ line指定换行符为lf，在 Linux 和Windows下可能会因为换行符lf和crlf的不一致导致代码被批量更改，insert_ final_ newline设为true表示文件以一个空白行结尾， trim_ trailing_ whitespace设为true会去除换行行首的任意空白字符。

Webstorm编辑器默认已经内置了EditorConfig的插件支持，只需要编写配置文件即可，VSCode需要下载EditorConfig的插件使用。

与版本管理工具结合

以版本管理工具Git为例，当版本库中出现commit、push等特殊事件时，都会触发执行一个或者多个的 Shell 脚本，称之为git钩子，存放在.git/hooks目录下，钩子从执行顺序上分为两类，前置（pre）和后置（post），分别发生在动作调用前后。 ESLint结合版本管理工具Git可以最大程度控制每个人的规范，在git commit代码的时候，使用git hook调用ESLint进行代码规范验证，这样可以保证团队协作的代码是符合代码规范的，不规范的代码无法提交到仓库。

配置Git钩子的过程比较繁琐，我们可以使用husky这个工具来简化配置，husky使用如下：

安装依赖：

修改package.json，增加script配置：

尝试Git提交，会自动使用eslint进行校验：

但是这样会出现新的问题：如果一个老项目刚开始使用这种方式进行代码校验，势必会出现很多代码校验不通过的情况。那么最好的实现应该是开发者在commit代码的时候只校验自己提交的部分，lint-staged解决了这个问题，statged指Git中的待提交区，使用git add然后git commit的时候，你的代码会经过待提交区。 lint-staged使用方法如下：

修改package.json中的script配置：

也可以使用如下配置自动修复错误：

husky会在.git/hooks中添加pre-commit钩子，当开发者执行git add将代码提交到暂存区后，再执行git commit操作时，触发pre-commit钩子，开始执行npm run precommit命令，即lint-staged命令，lint-staged利用配置的文件过滤路径如（src/ */ .js），对暂存区文件依次进行匹配，运行eslint --fix自动修复错误，并将修改添加到暂存区。

总结

代码是写给人看的，顺便让机器运行。遵循统一的代码规范在团队协作中可以极大提高开发效率，降低代码维护成本，而前端工程化可以让这件事情变得更简单。