前端代码规范工程化实践指南
栏目: JavaScript · 发布时间: 6年前
内容简介:ESLint是当前最流行的代码规范检查工具,随着ECMAScript版本一直更新,通过配置检查规则来对代码进行规范检查,具有丰富的插件生态,也可以使用已有的规范以及进行自定义规则,可以满足大部分团队的需求。
现代前端技术飞速发展,前端已进入了以效率和质量为核心的工程化时代,各种自动化 工具 和技术的使用大大提高了开发效率。在团队协作中,编码规范至关重要,统一的编码规范可以降低代码维护的成本,但是,纯手工检查代码规范费时费力且难以保证准确性,因此,针对代码规范的自动化工具应运而生,从最早的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自动修复错误,并将修改添加到暂存区。
总结
代码是写给人看的,顺便让机器运行。遵循统一的代码规范在团队协作中可以极大提高开发效率,降低代码维护成本,而前端工程化可以让这件事情变得更简单。
今日推荐
以上所述就是小编给大家介绍的《前端代码规范工程化实践指南》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!
猜你喜欢:本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。