ESLint

发表于   |   分类于   |   阅读次数 43

方法论

通过静态检查来提前发现一些低级的错误、以及进行编码风格的确定。

JavaScript 是一个动态的弱类型语言，在开发中比较容易出错。因为没有编译程序，为了寻找 JavaScript 代码错误通常需要在执行过程中不断调试。像 ESLint 这样的可以让程序员在编码的过程中发现问题而不是在执行的过程中。
 —— http://eslint.cn/docs/about/

ESLint的本身设计哲学：

  • 所有都是可拔插的
    • 内置规则和自定义规则共用一套规则 API
    • 内置的格式化方法和自定义的格式化方法共用一套格式化 API
    • 额外的规则和格式化方法能够在运行时指定
    • 规则和对应的格式化方法并不强制捆绑使用
  • 每条规则:
    • 各自独立
    • 可以开启或关闭（没有什么可以被认为“太重要所以不能关闭”）
    • 可以将结果设置成警告或者错误
  • 另外:
    • ESLint 并不推荐任何编码风格，规则是自由的
    • 所有内置规则都是泛化的
  • 项目:
    • 通过丰富文档减少沟通成本
    • 尽可能的简单透明
    • 相信测试的重要性

解决的问题

  • 编码的过程中发现问题而不是在执行的过程中
  • 规范编码风格

实现规范

http://eslint.cn/docs/user-guide/configuring

配置方法

  • Configuration Comments - 使用 JavaScript 注释把配置信息直接嵌入到一个代码源文件中。
  • Configuration Files - 使用 JavaScript、JSON 或者 YAML 文件为整个目录（处理你的主目录）和它的子目录指定配置信息。可以配置一个独立的 .eslintrc.* 文件，或者直接在 package.json 文件里的 eslintConfig 字段指定配置，ESLint 会查找和自动读取它们，再者，你可以在命令行运行时指定一个任意的配置文件。

配置信息

  • Environments - 指定脚本的运行环境。每种环境都有一组特定的预定义全局变量。
  • Globals - 脚本在执行期间访问的额外的全局变量。
  • Rules - 启用的规则及其各自的错误级别。

常见关于配置Rules的问题

我们经常见到的Rules有两种 

{
    "rules": {
        "eqeqeq": "off", // 第一种
        "quotes": ["error", "double"] // 第二种
    }
}

一种是只有一个参数，一种是有两个元素的数组。

对于只有一个参数的，它的含义和值定义如下，取值范围只有['off', 0, 'warn', 1, 'error', 2]：

  • "off" 或 0 - 关闭规则
  • "warn" 或 1 - 开启规则，使用警告级别的错误：warn (不会导致程序退出)
  • "error" 或 2 - 开启规则，使用错误级别的错误：error (当被触发的时候，程序会退出)

对于有两个元素的数组，第一个元素和一个参数的含义一致。第二个元素会作为参数传入本条规则，用于进行一些额外的、更加详细的配置。

命令行

命令行工具，在构建过程、代码提交流程中发挥重大作用。

--fix参数

eslint --fix
 这个参数是指示eslint尽可能自动修复最多的规则，注意并不是所有规则都可以自动修复，一般修复的都是格式相关的。具体哪些可以修复，在官网中有橙色扳手的规则是可以自动修复的。并且修复之后会自动写入文件系统中，即覆盖原有文件

配套工具

husky

  1. 地址
  2. 解决的主要问题：可以方便地把git的钩子（更多关于gitHooks）抛出来使用
  3. 使用方法：在package.json中添加如下代码即可 
// husky v1.0.0以上接口，如果使用0.14版本，可以上github上查询下用法
// package.json
{
  "husky": {
    "hooks": {
      "pre-commit": "npm test",
      "pre-push": "npm test",
      "...": "..."
    }
  }
}

lint-staged

看完上面的husky之后，自然而然就有想法，想在提交之前跑一下ESLint，防止那些没有注意的💩 跑到我们的代码仓库中。
 lint-staged就是接着处理的一个工具，现在我们有了pre-commit的钩子，怎么实现上面的想法呢。
 在pre-commit这个时机，代码其实是已经被git add到了本地暂存区（英文叫staged，这也解释了为什么工具名称叫lint-staged了）。这个时候运行下eslint --fix，就可以把本地的凌乱代码风格，修复到大家都接受的程度，然后再把修改之后的代码git add到暂存区中。钩子处理的事情结束，接着执行git commit。
 这样就达到了我们最初的目的：在git commit过程中，无感知地修复代码风格，避免💩合进我们的代码仓库中
 具体配合husky的配置文件可以这么写： 

// husky v1.0.0以上接口，如果使用0.14版本，可以上github上查询下用法
// package.json
{
  "husky": {
    "hooks": {
      "pre-commit": "lint-staged"
    }
  }
  "lint-staged": {
    // key是一个glob模式文件选择器，value是一个命令数组，串行执行
    "*.js": ["eslint --fix", "git add"]
  }
}

glob模式，了解更多

题外话

关于ESLint的演变历史，也是一个非常有趣的话题，记得我在读大学的时候，最流行的还是JSHint和JSLint，但是现在都已经不见踪影了。
 他们具体的演进历史是JSLint到JSHint，最后是我们看到的ESLint。具体可以戳这里，看这些语言、框架或者工具的演变进程是一件很有趣的事情，可以学到怎么才能不被淘汰，什么样的设计哲学是能经得住时间和大众开发者们考验的。

Comments
Write a Comment