目前在梳理前端应用时发现很多代码不规范的地方,包括简单的js问题以及代码格式化的问题,造成了代码可读性下降,另外各种历史代码也是“风格迥异”,甚至影响了应用质量。应用开发成员大部分由于之前是开发后端,对前端开发经验不足以及许多前端知识体系都是在开发过程中现学现用慢慢积累的,另外,痛定思痛总在想对于前端应用代码质量是否也存在诸如Java开发规约扫描插件,类似的前端代码质量扫描插件进行把控。经过查阅资料,采用eslint+husky+prettier+lint-staged
方式来对前端质量进行一定程度上的提升,之所以采用这样的方式,针对的痛点如下:
针对以上痛点,采用eslint+husky+prettier+lint-staged
这几个工具能够有效解决上述问题,其中执行流程和原理在下面给出(同时关于对代码质量文化另一个抓手—CR也可见于这篇文章)。
要想防患于未然,防止将存在潜在问题的代码带到线上环境,最好的办法是在本地提交代码时就能够扫描出潜在的错误,并强制将其修改后才能提交,这样就不会将问题代码携带到线上,就能保证线上代码至少不会存在低级的程序错误。针对这样的诉求,可以采用husky、lint-staged、eslint以及prettier
插件来实现,具体效果如下:
如上图,当试图commit代码时,由于扫描出错误就不能进行提交成功,必须将其修改成功方可commit。
在前端应用中的package.json
中新增如下文件:
{
"scripts": {
"precommit": "lint-staged"
},
"lint-staged": {
"src/**/*.js": [
"eslint --fix --ext .js",
"prettier --write",
"git add"
]
},
"devDependencies": {
"eslint": "^5.0.0",
"eslint-config-ali": "^2.0.1",
"eslint-plugin-import": "^2.6.0",
"eslint-plugin-react": "^7.1.0",
"husky": "^0.14.2",
"babel-eslint": "^8.1.1",
"lint-staged": "^4.0.0",
"prettier":"^1.16.4",
"eslint-plugin-prettier":"^3.0.1",
"eslint-config-prettier":"^4.0.0"
},
}
增加.eslintrc.js
扫描规则:
module.exports = {
"extends": ["eslint-config-ali","prettier", "plugin:prettier/recommended"],
"parser": "babel-eslint",
"rules": {
"prettier/prettier": "error",
"strict": "off",
"no-console": "off",
"import/no-dynamic-require": "off",
"global-require": "off",
"require-yield": "off",
},
"plugins": ["prettier"],
"globals": {
"React": "readable"
}
};
增加.prettierrc.js
文件,用于在扫描通过后格式化代码(该步骤可选,如果不引入prettier的话,相应的在package和eslintrc中去除掉相应配置即可)
module.exports = {
printWidth: 80,
semi: true,
singleQuote: true,
trailingComma: 'none',
bracketSpacing: true,
jsxBracketSameLine: false,
arrowParens: 'avoid',
requirePragma: false,
proseWrap: 'preserve'
};
在前端工程中引入以上的配置文件即可,这样就可以达到1.3中的效果。置于其中的实现原理在下面进行分析,有兴趣的可以继续往下看
达到上述效果,执行的流程如下:
在上述流程中,有这样几个核心点:
在2.1中的执行流程中主要使用到eslint,lint-staged等插件,下面分别对这几个插件进行说明。
lint是什么?
lint是对前端代码按照代码规则进行静态扫描的工具,主要负责对当前本地代码进行规范检查,如果不符合当前制定的规范则lint则会报出error,并且和lint-staged结合使用就会保证未通过代码规范的检查不能被提交到远程分支上,这样就能保证线上代码的质量。
为什么要引入eslint?
引入eslint在我的思考中可以具备如下的优点:
eslint --fix
可以根据规范对代码的部分低级问题进行更正。怎样使用eslint?
按照文章开头给出的package.json
进行配置即可,关于lint的使用可以看官方文档,eslint配置的代码规范也在文章给出的eslintrc.js
中给出,所谓代码规范自然而然是根据团队现状指定的,我们当前采用的是阿里前端规范eslint-config-ali
,当然也可以按根据现状”因地制宜“的去制定。另外需要指出的是,在eslintrc.js
配置文件中配置了globals
变量:
"globals": {
"React": "readable"
}
这是因为前端使用的React框架,eslint会对React等变量进行扫描会报出no-undefined
的error,需要另其为global变量才能避开扫描。在eslint的rules的设计中是可配置化的,在rules
的属性中可以设置,具体eslint的rule可见官方文档,其中打勾的是eslint:recommended
推荐使用的规则。
试想如果将代码已经push到远程后,再进行扫描发现多了一个分号然后被打回修改后才能发布,这样是不是很崩溃,最好的方式自然是确保本地的代码已经通过检查才能push到远程,这样才能从一定程度上确保应用的线上质量,同时也能够避免lint的反馈流程过长的问题。
那么什么时候开始进行扫描检查呢?这个时机自然而然是本地进行git commit
的时候,如果能在本地执行git commit操作时能够触发对代码检查就是最好的一种方式。这里就需要使用的git hook。
什么是git的hook
git的hook可以理解成当执行如git add、git commit
等git操作时的回调,可以查看.git
文件下的hooks目录,这里存放的是git相关操作的一些脚本例子。通过git hook就可以在本地进行commit的时候触发代码扫描来确保本地代码的质量。关于git hook可以看这篇文章。
在使用eslint和husky能够保证代码的质量问题,但是在实际工程中却还必须面临一个问题。现实情况下,一个应用一般是多个开发参与,并且在应用的生命周期中还涉及到人员变更,这就意味着一个应用是被来自”五湖四海“人共同维护,难不免有”广式烧腊、天津狗不理“各种口味,更难免的还有”臭味相投“的。
针对这些历史代码时,如果提交代码时,对其他未修改文件都进行检查,一下出现成百上千个错误,估计会吓得立马删掉管理eslint的配置,冒出一身冷汗。如下图所示(来源于网络)
修改了A文件,B、C、D等文件的错全部都冒出来了。针对这样的痛点问题,就是每次只对当前修改后的文件进行扫描,即进行git add加入到stage区的文件进行扫描即可,完成对增量代码进行检查。如何实现呢?这里就需要使用到lint-staged
工具来识别被加入到stage区文件。关于lint-stage可以看官方文档,现在会过头来看package.json
文件就能够理解其中的意思:
"scripts": {
"precommit": "lint-staged"
},
"lint-staged": {
"src/**/*.js": [
"eslint --fix --ext .js",
"prettier --write",
"git add"
]
},
在进行git commit的时候回触发到git hook进而执行precommit,而precommit脚本引用了lint-staged配置表明只对git add到stage区的文件进行扫描,具体lint-staged做了三件事情:1. 执行eslint --fix操作,进行扫描,若发现工具可修复的问题进行fix;2. 执行prettier脚本,这是对代码进行格式化的,在下面具体来说;3. 上述两项任务完成后对代码重新add。
Prettier工具主要用来统一代码格式的,eslint也会对代码进行一定程度的格式校验,但主要是用来对代码规范的扫描,而prettier则是专门用来对代码进行格式化,两个工具各司其职,为代码质量进行保驾护航。它的主要原理是将格式化前的代码和格式化后的代码进行比对,如果发现不一样,prettier就会对其进行标记并按照指定的格式化规范进行修复。下面的图可以看出prettier的能力(配套来源于网络)
可以看出prettier能够对代码进行格式化,这样就可以保证代码的可读性。perttier能够支持多种格式如JSX、HTML等等,具体可查看官方文档,对代码格式化标准可以根据团队现状共同来决定。
与eslint配合使用的插件
为了和eslint配合使用需要引入两个插件eslint-plugin-prettier和eslint-config-prettier
,其中需要说明的是eslint-config-prettier
插件的作用,这个插件是如果eslint的规则和prettier的规则发生冲突的时候(主要是不必要的冲突),例如eslint 限制了必须单引号,prettier也限制了必须单引号,那么如果用 eslint 驱动 prettier 来做代码检查的话,就会提示2种报错,虽然他们都指向同一种代码错误,这个时候就会由这个插件来关闭掉额外的报错。关于eslint-config-prettier
可以看它的官方文档。
在实际开发中可以在IDE中安装适配的插件来提升开发效率,安装开发插件后在编码的时候如果存在不符合规范的地方会有红色的波浪线提示,并且有一键fix的功能,这样能够提升效率。下面以webstorm举例
eslint的插件安装方式
如图,在webstorm中只需要指定eslint的配置文件即可。
prettier插件的安装方式
如图,webstorm已经内置了prettier功能,只需要保证当前工程已经安装了prettier package即可。
通过引入以上这些工具能够在一定程度上保证应用的质量问题,并能达到事半功倍的效果。但归根结底,对代码质量的提升需要自身与内心达成契约,也需要团队之间志趣相投。对代码质量能够保证最起码的“洁癖”,如果和coder这项事业,确认过眼神他就是对的人,那么也请和他一起往后余生,内心所至,全都是你。
git commit前检测husky与pre-commit
使用 ESlint、lint-staged 半自动提升项目代码质量
用 husky 和 lint-staged 构建超溜的代码检查工作流
梳理前端开发使用eslint和prettier来检查和格式化代码问题
AlloyTeam ESLint 配置指南
使用ESLint+Prettier来统一前端代码风格
用eslint + prettier + pre-commit管理项目(React)
React-native ESLint & Prettier & Pre-commit Hook配置
用eslint + prettier + pre-commit管理项目(React)
Prettier介绍与基本用法