前端代码规范工具ESLint和Prettier

1. ESLint是什么？

ESLint 是一个开源的 JavaScript 代码检查工具，由 Nicholas C. Zakas 于2013年6月创建。代码检查是一种静态的分析，常用于寻找有问题的模式或者代码，并且不依赖于具体的编码风格。对大多数编程语言来说都会有代码检查，一般来说编译程序会内置检查工具。

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

ESLint 的初衷是为了让程序员可以创建自己的检测规则。ESLint 的所有规则都被设计成可插入的。ESLint 的默认规则与其他的插件并没有什么区别，规则本身和测试可以依赖于同样的模式。为了便于人们使用，ESLint 内置了一些规则，当然，你可以在使用过程中自定义规则。

目前前端的标准Linter 是 ESLint：https://eslint.cn/，。它的目标是提供一个插件化的javascript代码检测工具。

2. Prettier是什么？

官网定义：

一个“有态度”的代码格式化工具

支持大量编程语言

已集成到大多数编辑器中

几乎不需要设置参数

Prettier官网：https://www.prettier.cn/，它的目标是保存代码时，代码就被格式化了，无需争论代码样式，节省时间和精力。

3. ESLint和Prettier有什么区别？

功能职责不同

ESLint主要偏向于把控项目的代码质量

Prettier主要偏向于统一项目的代码风格

作用不同

ESLint 自动扫描JS文件用来查找常见的语法和样式错误

Prettier 扫描文件用来查找样式问题并自动重新格式化代码，以确保在缩进、间距、分号、单引号与双引号等方面遵循一致的规则

4. 常见问题

4.1 Lint/Linter 开发工具，如Closure Linter是什么

Linter 主要的功能就是用一堆规则来提高代码质量，这些规则又大致可分为两类：

1.代码质量规则

这类规则可以理解为比语法错误更轻的一种警告，主要用来防止你的代码出现一些潜在错误，

比如推荐使用 const 和 let 声明变量会更安全：

var a = 1; // Badconst a = 1; // Good

2.代码风格规则

这类规则比上面的规则更轻一点，主要提醒你代码是不是写的太丑了，让代码更好读一点，

比如每行长度不超过 80 个字符：

const foo = { "bar": "This is a bar.", "baz": { "qux": "This is a qux" }, "difficult": "to read" }; // Badconst foo = { // Good"bar": "This is a bar.", "baz": { "qux": "This is a qux" }, "difficult": "to read"
};

4.2 JS Lint 历史

Lint 最初起步是因为常见的代码问题不能被编译器捕获，开发Lint / Linter 的附加工具来解决这些问题。

JS Lint 主要用来解决以下问题：

避免最初设计中存在的不少糟粕，提倡更多地使用 Good Parts
发现一些 JS 代码中存在的问题，例如忘记声明而导致的全局变量
保证代码风格统一，便于大型项目维护

开山鼻祖JSLint： https://www.jslint.com/

JSLint 是公认的第一个 JS Linter，由赫赫有名的老道－Douglas Crockford 在 2002 发布。彼时的前端还处于萌芽状态，大部分人还是用 JS 来写一些非常粗糙的页面效果、表单验证。JQuery 也要在四年之后才正式发布。

JSLint 的核心是 Top Down Operator Precedence（自顶向下的运算符优先级）技术实现的 Pratt 解析器。Pratt 解析器的处理结果本质上类似于 AST（抽象语法树）。

继往开来 JSHint：https://jshint.com/

在随后的前端跨越式发展中，JSLint 的一些不足暴露了出来。2011 年 12 月 20 日，Anton Kovalyov 发表了一篇标志性的文章：Why I forked JSLint to JSHint，指出了 JSLint 存在的几个主要问题。

JSHint 就是在这样的背景下诞生了：

And, as we were saying from the day zero, it will always be a community-driven tool. Simply because a community of programmers working together is better than a single person working alone. No matter who this person is.

它的核心定位是社区驱动的代码质量工具，因为 Anton 坚信程序员组成的社区一起协作要好于单打独斗。

在核心实现仍然基于 Pratt 解析器的基础上，借助社区的共同努力，JSHint 进行了多方面的改进：

1.更多可配置的规则
这是社区的核心诉求。除了开放规则的 Pull Request 外，JSHint 在规则文档、预定义环境方面也做了诸多努力

2.代码模块化
JSLint 源文件只有一个 5000 余行的大文件，对于一般开发者来说难以维护。JSHint 按照功能划分为 lex、scope、core、reporter 等多个模块，功能更聚焦

3.CLI
命令行工具的支持，为很多第三方工具提供了基础，JSHint 可以很好地和各种 IDE 集成

4.测试
JSLint 一行测试代码也没有，JSHint 的整体代码测试覆盖率达到了 99%

重新出发 ESLint：https://eslint.cn/

JSHint 在第三版的计划中有这样一条：

Build a foundation for plugins by exposing AST and adding additional hooks.

前端爆发式增长带来的巨大需求让 JSHint 变得愈加难以应对，通过暴露 AST 信息来支持第三方插件无疑是一剂良方。然而理想总是美好的，现实却非常残酷。这一计划直到现在仍然没有实现。究其原因，在 JSLint 时代就存在的规则检查和 Pratt 解析器深度耦合首当其冲，可谓是成也萧何败萧何。

2013 年，前端界另外一名标杆性人物 Zakas 在业务开发中遇到一个 XMLHttpRequest 在 IE7 中的问题，他希望使用 JSHint 来避免类似问题。Zakas 找到 Anton，了解到插件的提案被搁置并且短期内看起来没有希望去实施。

Zakas 首先在公司使用的一个 PHP Linter 上得到了一些启示，因为那个 Linter 使用了 AST 作为中间表示层，所有的规则都基于 AST 做进一步分析。他开始调研 JS 是否有类似工具，Ariya 开发的 Esprima 进入了他的视线。Zakas 盛情邀请 Ariya 到他的公司 Box 做一次不限主题的分享，而 Ariya 选择的主题恰恰是 Esprima。分享过程中，Ariya 介绍到了 AST 表示层的意义以及目前基于它的很多工具，例如遍历 AST 的工具 Estraverse 以及作用域分析工具 Escope。这一切让 Zakas 受益匪浅，下一代 JS Linter 工具的方案在他脑海中渐渐清晰起来。

很快，在 2013 年六月份的一个周末，Zakas 完成了第一个可执行的版本。借助于 Esprima 等工具，ESLint 的核心代码只有 100 行：

api.verify = function(text, config) {...// 添加规则Object.keys(config.rules).forEach(function(key) {var rule = rules.get(key);if (rule) {rule(new RuleContext(key, api));} else {throw new Error("Definition for rule '" + key + "' was not found.");}});// 解析代码，生成 ASTvar ast = esprima.parse(text, { loc: true, range: true }),walk = astw(ast);// 核心逻辑：遍历 AST 各个节点walk(function(node) {// 将当前节点通过事件进行分发，监听这些类型节点的规则会执行自己的检查逻辑api.emit(node.type, node);});// 返回检查结果信息return messages;
};

规则的实现完全和 Linter 核心逻辑分离，以全等（eqeqeq）规则为例：

// eqeqeq rule
module.exports = function(context) {// 监听遍历 AST 中触发的 BinaryExpression 事件context.on("BinaryExpression", function(node) {// 对这一类型节点的操作符进行检查var operator = node.operator;if (operator === "==") {context.report(node, "Unexpected use of ==, use === instead.");} else if (operator === "!=") {context.report(node, "Unexpected use of !=, use !== instead.");}});
};

这种架构带来了很多好处：

关注点分离
支持自定义规则
保持内核的简单

总结：

下图是 Google Trends 中 JSHint, JSLint, ESLint 关键字搜索次数的趋势图：

下图是 NPM Trends 中 ESLint，JSHint 和 JSLint 关键字搜索次数的趋势图：

参考：
https://www.prettier.cn/
https://www.jslint.com/
https://jshint.com/
http://eslint.cn/docs/about/
https://juejin.cn/post/6844904159670435854
https://zhuanlan.zhihu.com/p/34656263