基于eslint和husky的代码规范配置

581 阅读3分钟

    来到公司接了一个大活儿,电子合同项目。

    这个项目的背景是这样的,整个项目包括三个平台,两个pc端一个移动端。由于开发任务量大,前端团队又是新组建的。所以采用的策略是利用电子合同部门的老代码进行改造开发。

    这里有两个点,提炼一下。

  1. 多人开发的协同开发模式
  2. 老项目代码二次开发

    开发到后面我准备进行代码规范化,提高代码质量。那么之前提到的两点就对后面我的配置选择和规范优化带来一定的影响和风向的抉择问题。下面我一步步说下配置的过程及思路:

首先,想到要用的肯定有eslint

    eslint的主要功能是代码检验。于是,初步就是vue + eslint。vue-cli自带有代码的lint校验,引用eslint后,可以根据eslintrc.js配置文件进行更具体的规则细化工作。需要安装的npm包如下

"@vue/cli-plugin-eslint": "^3.9.1",
"@vue/eslint-config-standard": "^4.0.0",
"babel-eslint": "10.0.1",
"eslint": "^5.15.3",
"eslint-config-prettier": "^8.1.0",
"eslint-friendly-formatter": "4.0.1",
"eslint-loader": "^4.0.2",
"eslint-plugin-html": "^6.0.3",
"eslint-plugin-import": "^2.20.2",
"eslint-plugin-prettier": "^3.3.1",
"eslint-plugin-vue": "^5.2.2",

    有些脚手架自带,有些需要手动安装。OK,eslint有了以后,配置eslintrc.js配置文件。终端执行eslint --fix就可以进行代码格式校验了,而且框框的报错就出来了。。。。

第一步,校验代码就有了

其次,引入husky

    为什么要用husky呢?这里就是之前的两个问题的前提导致的。老代码二次开发。由于这个原因,以前的代码会有非常多的格式错误问题。这个时候如果去一一改过来才能运行项目,没时间。如果绕过eslint校验功能,直接可以启动项目,代码规范名存实亡。为了解决这个问题install husky

    简单解释下husky,它是一个针对git的hook钩子集合。在不同的git命令阶段可以进行回调操作。比如,git cmmit命令,就可以用pre-commit这个hook就行提交前的拦截操作。这个功能的好处是,他只针对本次commit修改的文件进行eslint校验,如果校验不通过,不允许你提交代码。其他代码不受影响。完美解决前面说到的这个问题了。

    npm需要引用的包就是husky了,我用的4.0版本,因为5.0变化比较大,而且貌似收费的感觉。没有去研究它

package.json中的husky设置如下

"husky": {
    "hooks": {
      "pre-commit": "lint-staged"
    }
  },

    这样,husky就会在你提交的时候执行lint-staged命令了。接下来就说下lint-staged

lint-staged

    lint-staged会对git的缓存区文件进行扫描,而不是整个文件,目的是为了提速的。install lint-staged

package.json写入如下命令

"lint-staged": {
    "src/**/*.{js,vue}": [
      "eslint --fix",
      "prettier --write"
    ],
    "*.{png,jpeg,jpg,gif,svg}": "imagemin-lint-staged"
  },

husky的hooks在执行pre-commit的时候就回去执行lint-staged这个命令了,接下来依次执行lint-staged里边的命令。

锦上添花prettier

    lint-staged命令里边执行了一个prettier命令,这里简单介绍下,prettier这个插件的主要目的是自动格式化你的代码,美化用的,可有可无,官网了解下吧。

    到这里,一个检验代码规范并修复一般问题的配置就差不多配好了。

    所以整套配置用到的插件有:eslint、husky、lint-staged、prettier

    如果像更加完善的话,后面还可以用到git flow、 commitlint等工具对commit提交进行规范化