Eslint详解——前世今生及使用教程
前言：当刚拿到Eslint的时候，我是一头雾水的。它是什么？与JsLint、JsHint、JSCS有什么区别？怎么用？是否能应用到我们的项目上？本文希望能解答你以上的困惑。废话不多说，让我们抓紧开始吧。
1 起源
JS是一门强大的语言，但是它也有很多不良的特性。这些特性会导致你的代码出现一些不可预期的错误。另外，当一个项目中有了多位开发人员之后，整个项目变得难看了起来—— A习惯于用分号结尾，而B沉迷于直接使用换行符；糟糕的是，这种情况还有很多。整个项目的风格迥异，给阅读和维护都带来了一定的困难。
JsLint:
为了解决这个问题，2010年7月，Douglas Crockford编写了JsLint。他最初的想法用一些既定的规则分析我们的JavaScript代码，把潜在的Bug和不良代码全部找出来。而Lint是最著名的C语言编译工具，它比其他编译工具更加严密，提供更加广泛的错误分析，这就是Douglas将这个工具命名为JsLint的原因。后来大家发现使用这个工具之后，编写出来的代码更像是一个人书写的代码，增加了代码的可维护性，这就是后话了。
JsHint:
但是Douglas是一个纯粹的处女座，他将认为的非Good Parts的部分都报了warning，而且在它的文档中也提到了你应该欣然接受所有的JSLint的建议。而且他的绝大部分规则都不能被改变。所以很多人在这种规则下备受压迫。Anton Kovalyov站了出来，开发了JsHint。相比于前者，JsHint有以下优点：
- 支持参数可配置
- 支持一些配置文件
- 支持一些常用类库
- 支持基本的ES6
EsLint:
终于不用生活在Douglas的阴影下了，普天同庆，程序员们留下了激动的泪水。但是很快大家又有了新的需求：
- JsHint不支持自定义规则
- JsHint不能根据错误定位到具体的规则
于是，Nicholas C. Zakas在2013年开始开发了Eslint，使开发者能自定义自己的linting rules，而且它提供了一套相当完善的插件机制，可以自由的扩展，动态加载配置规则，同时可以方便的根据报错定位到具体的规则配置。而且可以支持JSX（当前唯一一个）。
JSCS:
JSCS和上面的三种略有区别。它不会做任何事除非你赋给他一个配置。另外它更多的是一个code style的规范，而不会对可能隐藏的bug进行报告，例如没有使用的变量，或者是错误定义的全局变量。另外它在这四个里面是最慢的。
综上而言： 无脑选择Eslint就可以了，它灵活，全面可以自定义并且可以监测一些可能会出现的Bug。
2 使用
光说不练假把式，下面就罗列一下Eslint的使用方法。
和jsHint直接把规则写好了，只需要安装插件就能用不同，eslint需要在装好插件之外，额外添加自己的或者别人写好的规则。
eslint是非常灵活的，它允许你打开和关闭任意一条规则，来拼装最适合你的。有三种配置eslint的主要方法：
使用JS注释的方法直接将配置信息嵌入到一个文件中
/* eslint no-comma-dangle:1 */ // Make this just a warning, not an error var obj = { key: 'value', }将配置信息写在.eslintrc文件中（支持json和YAML）
{ "env": { "browser": true, }, "globals": { "angular": true, }, "rules": { "accessor-pairs": [2, { "getWithoutSet": true }], "array-callback-return": 1, "block-scoped-var": 2, "complexity": 0, ... } }将配置信息写在package.json中eslintConfig块中
{ "name": "mypackage", "version": "0.0.1", "eslintConfig": { "env": { "browser": true, "node": true } } }
像CSS的优先级一样，若子目录下有相应的配置，则会覆盖根目录下的配置。
eslint的具体配置内容文档可以参考《eslint中文文档》。当然，也可以选择别的大机构/公司已经写好的配置——例如安装airbnb和facebook的插件。