ESLint + lint-staged 禁用老项目中的es6

前言

ESLint做为插件化的javascript代码检测工具,为咱们的平时的开发保驾护航,好处就很少说了详情查看官网javascript

问题

有这么一个五年前开发的老项目,机缘巧合到了咱们这边来维护。
项目是zepto撸起来的,单个文件巨大,只有gulp+公司内部古老的打包工具作了下简单的打包。 可是问题很严重的是,如今es6写习惯了,在老项目时总会有些地方会忽略掉直接用了es6的语法。
这种未经babel转译的代码,然而在当前的现状是大部分浏览器是能够运行的,
只有以蓝绿厂为表明的部分国产手机未支持。测试的时候没有进行全机型的覆盖。致使上线后出问题。在这样的背景下进行了讨论,怎么处理这种老项目。java

解决方案

解决其实也很简单,无外乎下面三种node

项目迁移

时间充足,迭代频繁的状况下,首选迁移,否则zepto写的文件太大太难维护了。基于现状就pass调这条了。git

babel

既然是未转移的存在问题,转就完了。es6

语法检查

在提交以前,检测es6语法,确保不存在以后再容许提交。 权衡之下,选择了语法检查,顺带复习了下eslint的用法。github

安装

//能够全局安装
npm i -g eslint
//或者项目本地安装
npm i -D eslint
复制代码

安装以后,进行初始化(固然能够复用已有的.eslintrc.js):npm

eslint --init
//非全局安装 
./node_modules/.bin/eslint --init
//选择初始化类型 这里就看具体用途了
 How would you like to configure ESLint? (Use arrow keys)
  Use a popular style guide  //已有的流行规范,你们比较推崇的几种
❯ Answer questions about your style // 回答问题来定制
  Inspect your JavaScript file(s) // 检查已有js文件来生成 
复制代码

这里我直接选择了3,觉得会比较友好的直接生成。
后面依次以下:json

Which file(s), path(s), or glob(s) should be examined? ./js //待检测的目录
? What format do you want your config file to be in? JavaScript //配置文件即eslintrc.js的格式,固然是js喽
? Which version of ECMAScript do you use? ES5 //当前使用的ES5
? Where will your code run? Browser //浏览器
? Do you use CommonJS? Yes //CommonJS规范
? Do you use JSX? No //是否用了jsx,显然否
复制代码

结束以后,生成了咱们的配置文件:gulp

//太长,只关注咱们关心的部分吧
    //环境部分就是本身选择的
    "env": {
        "browser": true,
        "commonjs": true
    },
    // 扩展配置 eslint:recommended 是核心规则
    "extends": "eslint:recommended",
    // 支持的ECMAScript 规范,默认也是5
    "parserOptions": {
        "ecmaVersion": 5
    },
    // 检查规则,这里不详细表述
    "rules": {
        // ***
    }
复制代码

配置文件生成完成,那么直接干吧。直接执行看看:浏览器

// 检查 文件夹下面的文件
./node_modules/.bin/eslint ./js
复制代码

而后报了1020个错误。。。毕竟是老项目,符合规范也不现实。可是咱们的目的好像不像这么大费周章,只想禁用es6罢了。eslint提供了这个选项:直接false掉好了。rules其实咱们不须要,由于是老项目,也不想去作这个限制。因此配置文件被我改为了这样。

"env": {
        "es6":false
    },
    "parserOptions": {
        "ecmaVersion": 5
    },
    "rules": {
    }
复制代码

这样跑起来看还行,只把文件中的es6部分找出来了 可是这样又有个问题,这个庞大的老项目有文件数目太多。每次都要去检查js文件夹下的全部文件是有点浪费的。毕竟咱们有这个这样一个前提,此次未改动的认为是符合要求的(毕竟有问题也早被修复了),应该只关注此次改动部分。这样想的人多了,就有大牛造出下面的工具了。

lint-staged

在commit以前的检测会更有意义一些,这样错误代码就不会提交到仓库。去检测全部文件很慢且有的结果是可有可无的,你更改关心的是本次改动的内容。这就是lint-staged的用处。 安装及使用:

//切记lint-staged 和 husky要所有安装
npm install --D lint-staged husky
复制代码

husky 能够阻止坏的commit, push and more。方便咱们操做git hooks。
能够这样使用:

{
  //本身手动hook 
  "scripts": {
   "precommit": "npm test"
  },
  //使用husky
 "husky": {
   "hooks": {
     "pre-commit": "npm test"
   }
 }
}
复制代码

这里就提一下不要忘记安装这个工具,否则你会发现lint-staged配置完成以后没有起做用(我不想说我是怎么知道的。。。),更多请移步github主页 用法也很简单,在咱们的package中增长下配置就好

"scripts": {
    "precommit": "lint-staged"
  },
  "lint-staged": {
    "*.js": [
      "eslint",
      "git add"
    ]
  }
复制代码

这样,就是只检测本次commit中的js文件了。

那么结合lint-staged,咱们能够配下咱们的package.json

"scripts": {
    "precommit": "lint-staged"
  },
  "lint-staged": {
    "*.js": [
      "eslint",
      "git add"
    ]
  }
复制代码

结束

到这里,老项目禁止es6就完成了。简单测试下,覆盖还能够,起码经常使用的方法能够检测到。正好用到eslint+lint-staged,就大概看了下,巩固下原来不熟悉的地方,给本身也作个记录。但愿能对有须要的同窗有所帮助。

相关文章
相关标签/搜索