eslint+husky+prettier+lint-staged提高前端应用质量

时间 2019-11-05

标签 eslint+husky+prettier+lint eslint husky prettier lint staged 提高前端应用质量繁體版

原文原文链接

1. 引入扫描工具的初衷

1.1 针对痛点

目前在梳理前端应用时发现不少代码不规范的地方，包括简单的js问题以及代码格式化的问题，形成了代码可读性降低，另外各类历史代码也是“风格迥异”，一个应用是被来自”五湖四海“人共同维护，难难免有”广式烧腊、天津狗不理“各类口味，更不免的还有”臭味相投“的，这些状况严重影响了应用质量。应用开发成员大部分因为以前是开发后端，对前端开发经验不足以及许多前端知识体系都是在开发过程当中现学现用慢慢积累的，另外，痛定思痛总在想对于前端应用代码质量是否也存在诸如Java开发规约扫描插件，相似的前端代码质量扫描插件进行把控。通过查阅资料，采用eslint+husky+prettier+lint-staged方式来对前端质量进行必定程度上的提高，之因此采用这样的方式，针对的痛点以下：html

代码规范落地难：代码规约至关于团队乃至公司的整个技术团队协做的契约，同时这些规范是通过许许多多前辈大师通过项目的洗礼留下的宝贵财富能够在开发中少走不少的弯路，可是，面对开发规范常常面临的现状是很难落地，老是“拆东墙补西墙”，归根结底在于须要工具去强行保证代码必须通过代码开发规范的扫描；
低质量代码带入线上应用：在实际开发现状中开发人员能够很简单的执行git push操做将本地代码带入远程分支上，若是代码质量低下就很容易对线上应用质量埋下隐患，至于在合并的时候在进行CR，这样反馈链路太长，最好的方式本地进行commit的时候，最起码须要保证当前代码可以知足团队制定的开发规范，若是不经过，commit都没法成功，这样可以从最源头保证代码质量问题；
代码格式难统一：按照现状团队的开发成员对代码的格式都有很大的不一样，甚至有些人字符串喜欢用双引号，有的人喜欢使用单引号等等问题，若是代码格式化问题不统一，总以为互相查看其它人的代码总以为怪怪的，甚至代码格式错乱，严重影响了代码可读性，无疑也增长了团队内的沟通成本，针对这样的状况，须要一种工具可以保证团队内代码的格式是一致；
代码质量文化难落地：经过引入代码质量工具，在开发过程当中可以时刻对自身代码质量进行约束，逐渐培养自身对代码质量有“洁癖”的开发观念，同时也会成为团队乃至自身对质量文化落地的一个抓手。

针对以上痛点，采用eslint+husky+prettier+lint-staged这几个工具可以有效解决上述问题，其中执行流程和原理在下面给出（同时关于对代码质量文化另外一个抓手—CR也可见于《入Ali一年，对code-review的思考》）。前端

1.2 达成效果

要想防患于未然，防止将存在潜在问题的代码带到线上环境，最好的办法是在本地提交代码时就可以扫描出潜在的错误，并强制将其修改后才能提交，这样就不会将问题代码携带到线上，就能保证线上代码至少不会存在低级的程序错误。针对这样的诉求，能够采用husky、lint-staged、eslint以及prettier插件来实现，具体效果以下：java

如上图，当试图commit代码时，因为扫描出错误就不能进行提交成功，必须将其修改为功方可commit。react

1.3 配置文件

在前端应用中的package.json中新增以下文件：git

{
  "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扫描规则：github

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中去除掉相应配置便可）web

module.exports = {
  printWidth: 80,
  semi: true,
  singleQuote: true,
  trailingComma: 'none',
  bracketSpacing: true,
  jsxBracketSameLine: false,
  arrowParens: 'avoid',
  requirePragma: false,
  proseWrap: 'preserve'
};
复制代码

在前端工程中引入以上的配置文件便可，这样就能够达到1.3中的效果。置于其中的实现原理在下面进行分析，有兴趣的能够继续往下看npm

2. 实现原理

2.1 执行流程

达到上述效果，执行的流程以下：json

待提交的代码git add 添加到暂存区；
执行 git commit；
husky注册在git pre-commit的钩子函数被调用，执行lint-staged；
lint-staged 取得全部被提交的文件依次执行写好的任务（ESLint 和 Prettier）；
若是有错误（没经过ESlint检查）则中止任务，同时打印错误信息，等待修复后再执行commit；
成功commit，可push到远程

在上述流程中，有这样几个核心点：segmentfault

husky注册git的钩子函数保证在git 执行commit时调用代码扫描的动做；
eslint完成按照配置的规则进行扫描；
Lint-staged保证只对当前add到git stage区的文件进行扫描操做，这样作的缘由在于，若是对全工程的文件进行扫描的话，而且以前的前端工程并未注重代码规则的检测的话，很大可能性会出现成百上千的error，基本上内心是崩溃的。所以，只对当前add的文件进行检测，达到及时止损的目的，历史代码能够切到新的分支进行修复后再进行合并。

2.2 插件说明

在2.1中的执行流程中主要使用到eslint，lint-staged等插件，下面分别对这几个插件进行说明。

2.2.1 eslint

lint是什么?

lint是对前端代码按照代码规则进行静态扫描的工具，主要负责对当前本地代码进行规范检查，若是不符合当前制定的规范则lint则会报出error，而且和lint-staged结合使用就会保证未经过代码规范的检查不能被提交到远程分支上，这样就能保证线上代码的质量。

为何要引入eslint？

引入eslint在个人思考中能够具有以下的优势：

既然是代码扫描的工具，天然能够保证开发规约的落地，诸如java开发规约的扫描插件，对于前端而言eslint就是这样的一个工具，经过配置代码规范来确保指定的代码规约进行落地。常见的一些大厂的代码规范有阿里的前端规范，airbnb，鹅厂alloyteam团队等；
确保应用的线上质量，这点无须赘述，结合其余工具的使用，不知足代码规范的代码都不能push到远程分支上去；
更高的可读性，eslint会对代码质量进行扫描，而且通常结合prettier使用的话，在经过代码规范后能够对代码进行格式化，能够保证代码可读性；
避免低级的错误，经过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推荐使用的规则。

2.2.2 husky

试想若是将代码已经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能够看这篇文章。

2.2.3 lint-staged

在使用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。

2.2.4 prettier

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能够看它的官方文档。