前言
假定你是一位 Java 开发或是一位全栈开发者,并且曾经写出了一些你自己都不想看的前端代码,那么回想一下你有没干过这样的事:
.eslintrc文件是什么?打开看是一堆看不懂的配置,好像没啥用,不管了。package.json里的script字段里有个precommit命令npm run lint,提交代码commit之前运行会报一堆错,导致代码提交不上去,但项目急着上线哪,先干掉。lint命令是啥?从来没用过。
本篇文章希望能够解决你的以下问题:
ESlint是什么?- 为什么写前端项目一定要用 
ESlint? - 如何让你的编辑器支持 
ESlint的实时代码检查? 
什么是 ESlint?
先把ESlint 这个词拆开来看,ES代表 EcmaScript,是 JavaScript的语言标准,lint 顾名思义就是代码检查。所以Eslint要做的事情就是检查你的代码是否符合EcmaScript的代码规范,它的主要作用有两个:
- 避免低级错误
 - 统一代码的风格
 
很多时候前端同学用编辑器机器打开后端同学开发的代码通常能发现满屏的红:

如果手贱再跑个tnpm run lint 看看,2w多个错误 😂…

为什么要用 Eslint?
众所周知,JS 是个动态弱类型的语言,而 Java 是一个静态强类型的语言,正好处于坐标的两端,因此对于原本写着 Java 而需要写 JS 的同学来说,可能会有一些不习惯。

首先按. 出不来任何提示代码了(前端同学表示也希望能点出代码提示,鬼知道 object 里装的什么),其次变量类型只有 let和const两种,完全没有 java 那样的类型控制。所导致的结果就是代码出错的概率大大提高,且极难排查。
这种问题在多人合作开发的时候尤其明显,很多代码无法看懂,代码重构难度越来越大,历史遗留的债务越来越重,新人要理清楚业务逻辑很麻烦。你可曾听说过一句话”动态语言一时爽,代码重构火葬场“,尤其在前端这样一个轮子满天飞的领域,没有代码规范简直随手写出 bug。
前端同学被这些问题折磨得更凶猛。那么他们是如何解决这些问题的呢?
方式一,通过 TypeScript等强类型声明给 JS加上类型定义,VSCode 这样复杂度的软件就是用 JS 写的,更准确的说是 TS,目前 TS 获得越来越大的关注度,越来越多的项目开始使用 TS 开发。
另一个方式就是 Eslint,Eslint 是拯救不熟悉JS代码的同学写出漂亮规范前端代码的关键,不懂JS规范,不会配 Eslint?没关系,已经有很多公司和组织帮你整理了很多份,比如 eslint-config-airbnb,这个库在github 已经 63k 的 star了…
配置其实不是最重要的,任何前端脚手架都会帮你配置好 eslint 规则,最重要的是你要去遵守这个规则,在平时写代码的时候就去践行,然后让你的小伙伴也遵守同样的规则。这样事情就会向好的方面发展,一切的一切都是为了代码可读性和可维护性。试着修复代码里的 eslint 错误,从一两个文件开始,从下次写 JS 代码开始,你会发现遵守规则并不那么难,每个规则实际都有它存在的意义.。
什么?你说你的代码也跑出来2w多的的lint错误怎么办? 传授你终极大法:
// 把package.json里的lint命令加一个--fix命令行,eslint会帮你fix掉它能fix的"lint": "eslint . --fix",// 然后命令行运行$ tnpm run lint
是不是瞬间 1w 多的 lint 错误就没了? 别问我剩下的 1w 多错误怎么办,我也不知道…
编辑器支持
所以,上面啰嗦了那么久就是希望你能意识到代码规范的重要性。功夫在平时,事不宜迟,咱现在就配置一波编辑器让他们支持 Eslint 实时代码检查吧。你说你想配置 IntelliJ IDEA ? 编辑器换来换去好麻烦?对此我有一言相劝:
尽早选用合适的前端编辑器让你能够享受前端开发的各种便利。
推荐两款,轻便型机枪VSCode和重炮WebStrom,区别就像 Sublime 和 IDEA 那样吧,笔者目前两者都在使用,平时调调 Bug 用 VSCode 就好了,起个大项目老实用 WebStrom。
Webstrom
Webstrom 的 Eslint 支持需要自己开启(123步),且关闭 Webstrom 自带的 lint 规则(第4步)。
- 按 Command + 
,调出 Webstrom 配置页面。 - 左边栏调整到 Languages & Frameworks -> JavaScript -> Code Qulity Tools -> Eslint
 - 打开右边栏中的 Enable 按钮,点击 Ok。
 

- 继续按 Command + 
,调出 Webstrom 配置页面,点开 Editor -> Inspections,搜索 JavaScript,然后把所有 JavaScript 规则 x 掉,然后点开 Code quality tools,打开 Eslint。 

这样你的代码里只有 Eslint 在检查你的代码,编辑器默认的规则咱不管,留着干扰视线。实际上代码里还会有typo,你可以搜索 Spelling 把 typo 也干掉,通常他们用处也不大。
VSCode
VSCode 是通过插件支持 Eslint 的,而且 VSCode 本身不自带 lint 规则,所以你只需要安装好 Eslint 插件即可。
左侧栏最后一个为插件管理,搜索Eslint,安装,重启,搞定。安装完后默认就是开着的,插件会优先使用本地文件夹中安装的eslint,如果没有会用全局的,建议可以全局安装一个eslint: tnpm install -g eslint 。

注意点
- 配置文件是在
.eslintrc文件中,也有可能是.eslintrc.js或者.eslintrc.json。 - 代码中遇到一些实在无法lint的可以注释的方式临时关闭eslint检查 ```javascript / eslint-disable /
 
alert(‘foo’);
/ eslint-enable /
- 有一些文件你不想它被lint,可以写在`.eslintignore`文件中:
assembly/ coverage/ dist/ fntest/ mocks/ mocks_data/ node_modules/ run/ spm_modules/ ```
