由于效能问题,TypeScript 官方决定全面采用
ESLint,甚至把仓库(Repository)作为测试平台,而
ESLint 的 TypeScript 解析器也成为独立专案,专注解决双方相容性问题。

原文地址:

在团队协作中,为避免低级
Bug、产出风格统一的代码,会预先制定编码规范。使用 Lint
工具和代码风格检测工具,则可以辅助编码规范执行,有效控制代码质量。

在以前的项目中,我们选择 JSHint 和 JSCS 结合使用,WebStorm
等开发环境已经支持这些工具,使用起来很顺手。然而,最近使用 React JSX
语法时,却遇到了问题:JSHint 不支持 JSX
语法。虽然有 JSXHint 这样的 JSHint
衍生工具,但个人并不喜欢这样的实现方式:不是以插件的形式实现,而是重新重新包装了一个工具。Nicholas
C.
Zakas 也不喜欢,所以有了 ESLint。

原来选择 JSHint 的时候,也对比过 ESLint,基于 ESLint 在速度上比 JSHint
要慢一些,最终使用了
JSHint。现在需要 JSX 支持了,才发现 ESLint 的设计理念更符合实际需求。

图片 1

JavaScript 代码检验工具 ESLint 在 TypeScript 团队发布全面采用 ESLint
之后,发布 typescript-eslint
专案,以集中仓库解决
TypeScript 和 ESLint 相容性问题。而 ESLint 团队将不再维护
typescript-eslint-parser,也不会在 Npm 上发布,TypeScript
解析器转移至Github 的 typescript-eslint/parser。

ESLint 简介

ESLint 由 JavaScript
红宝书 作者
Nicholas C. Zakas 编写, 2013 年发布第一个版本。 NCZ
的初衷不是重复造一个轮子,而是在实际需求得不到 JSHint
团队响应 的情况下做出的选择:以可扩展、每条规则独立、不内置编码风格为理念编写一个
lint 工具。

ESLint 主要有以下特点:

  • 默认规则包含所有 JSLint、JSHint 中存在的规则,易迁移;
  • 规则可配置性高:可设置「警告」、「错误」两个 error
    等级,或者直接禁用;
  • 包含代码风格检测的规则(可以丢掉 JSCS 了);
  • 支持插件扩展、自定义规则。

ESLint 已经宣布支持
JSX,不过目前为 alpha
版本,正式版发布之前可以先使用 eslint-plugin-react 替代。

Update 2016.04.22:

ESLint 从 0.12.0 开始已经支持 JSX。
2016.04.14,JSCS 宣布合并至 ESLint。
2016.04.19,ESLint 宣布加入 jQuery 基金会。
无疑,无论现状,亦或前景,ESLint 都会是首选的 JavaScript 代码质量控制工具。

 

工欲善其事必先利其器,软件工程师每天打交道最多的可能就是编辑器了。入行几年来,先后折腾过的编辑器有
EditPlus、UltraEdit、Visual
Studio、EClipse、WebStorm、Vim、SublimeText、Atom、VSCode,现在仍高频使用的就是
VSCode 和
Vim 了。实际上我在
VSCode 里面安装了 Vim 插件,用 Vim
的按键模式编码,因为自从发现双手不离键盘带来的效率提升之后,就尽可能的不去摸鼠标。

图片 2

使用 ESLint

ESLint
详尽使用参见官方文档,下面罗列的是由
JSHint 迁移到 ESLint 的一些要点。

折腾过 Atom 的我,首次试用 VSCode 就有种 Vim 的轻量感,试用之后果断弃坑
Atom。Atom 之前,我还使用过
SublimeText,但它在保存文件时会不时弹出购买授权的弹窗,实在是令人烦恼。

在 TypeScript 的2019
上半年发展规划中,TypeScript官方说明了
Linting 工具的状况。由于在数个月前他们透过 VS Code
的问卷调查发现,不少用户认为 TypeScript 的 Linting 支援不足,因此负责
JavaScript 编辑体验的团队开始着手增加对 TSLint 和 ESLint 的支援。

配置

可以通过以下三种方式配置 ESLint:

  • 使用 .eslintrc 文件(支持 JSON 和 YAML 两种语法);
  • 在 package.json 中添加 eslintConfig 配置块;
  • 直接在代码文件中定义。

.eslintrc 文件示例:

{
  "env": {
    "browser": true,
  },
  "parserOptions": {
    "ecmaVersion": 6,
    "ecmaFeatures": {
      "jsx": true
    }
  },
  "globals": {
    "angular": true,
  },
  "rules": {
    "camelcase": 2,
    "curly": 2,
    "brace-style": [2, "1tbs"],
    "quotes": [2, "single"],
    "semi": [2, "always"],
    "space-in-brackets": [2, "never"],
    "space-infix-ops": 2,
  }
}

 

.eslintrc 放在项目根目录,则会应用到整个项目;如果子目录中也包含 .eslintrc 文件,则子目录会忽略根目录的配置文件,应用该目录中的配置文件。这样可以方便地对不同环境的代码应用不同的规则。

package.json 示例:

{
  "name": "mypackage",
  "version": "0.0.1",
  "eslintConfig": {
    "env": {
      "browser": true,
      "node": true
    }
  }
}

 

文件内配置

代码文件内配置的规则会覆盖配置文件里的规则。

禁用 ESLint:

/* eslint-disable */
var obj = { key: 'value', }; // I don't care about IE8  
/* eslint-enable */

 

禁用一条规则:

/*eslint-disable no-alert */
alert('doing awful things');  
/* eslint-enable no-alert */

 

调整规则:

/* eslint no-comma-dangle:1 */
// Make this just a warning, not an error
var obj = { key: 'value', } 

 

每每上手新的编辑器,我都会根据自己的开发习惯把它调较到理想状态,加上熟悉编辑器各种特性,这个过程通常需要几周的时间。接下来,我就从外观配置、风格检查、编码效率、功能增强等
4 方面来侃侃怎么配置 VSCode 来提高工作幸福感。

但是编辑器团队提到,TSLint 的规则运作方式存在架构性的效能问题,
如果要维持效能将需要不同的 API,而这将破坏既有规则,相反的 ESLint
则具有更高效能的架构,而且不少热门专案的社群,诸如 React Hooks 和
Vue,都是使用 ESLint 建构 Lint 规则。

工作流集成

ESLint
可以集成到主流的编辑器和构建工具中,以便我们在编写的代码的同时进行
lint。

编辑器集成

以 WebStorm 为例,只要全局安装 ESLint 或者在项目中依赖中添加 ESLint
,然后在设置里开启 ESLint
即可。其他编辑可以从官方文档中获得获得具体信息。

构建系统集成

在 Gulp 中使用:

var gulp = require('gulp');  
var eslint = require('gulp-eslint');

gulp.task('lint', function() {  
  return gulp.src('client/app/**/*.js')
    .pipe(eslint())
    .pipe(eslint.format());
});

 

其他构建工具参考官方文档。

外观配置

外观是最先考虑的部分,从配置的角度,无非是配色、图标、字体等,俗话说萝卜白菜各有所爱,我目前的配色、图标、字体从下图基本都能看出来,供大家参考:

图片 3

image

  • 配色:Solarized
    Dark,VSCode
    已经内置,使用了至少 5 年以上的主题,Vim 下的配置完全相同;
  • 图标:VSCode Great
    Icons,给不同类型的文件配置不同的图标,非常直观;
  • 字体:Fira
    Code,自从发现并开始使用
    Fira
    Code,我就再也没多看自其它字体一眼,字体如果比较优雅,尤其是对数学运算符的处理,写代码时你真的会感觉在写诗,哈哈,Fira
    Code 的安装过程稍微复杂点,但是效果绝对是值当的;

配色、图标、字体以及其他外观配置项具体如下(注意,如果不安装上述插件,部分配置项如果直接使用是无效的):

{
  "editor.cursorStyle": "block",
  "editor.fontFamily": "Fira Code",
  "editor.fontLigatures": true,
  "editor.fontSize": 16,
  "editor.lineHeight": 24,
  "editor.lineNumbers": "on",
  "editor.minimap.enabled": false,
  "editor.renderIndentGuides": false,
  "editor.rulers": [120],
  "workbench.colorTheme": "Solarized Dark",
  "workbench.iconTheme": "vscode-great-icons"
}

因此 TypeScript 的编辑器团队决定专注支援 ESLint,增加语义 Linting
和程式范围 Linting
等目前尚未包含的使用情境,同时,他们也承诺,会提供贡献以强化 ESLint 对
TypeScript 的支援,同时也在 TypeScript 储存库中使用
ESLint,使其成为工具实践的测试平台,并向上发送所有新规则。

代码风格检测

在团队协作中,统一的代码风格更具可读性、可维护性。ESLint
内置了一系列有关代码风格的规则,可以根据团队的编码规范设置。

风格检查

之前我写过一篇在 Git 提交环节保障代码风格的文章:《使用 husky 和
lint-staged
打造超溜的代码检查工作流》。如果编辑器在编码时实时给出反馈,对开发者个人而言才是最高效的,在提交时做强制检查只是从团队的视角保证编码风格的规范性和一致性。前端工程师会书写的代码无非是:HTML、CSS、Javascript、Markdown、TypeScript、JSON,对应的
Lint 工具就显而易见:

  • ESLint:插件式架构,有多种主流的编码风格规则集可供选择,典型的有
    Airbnb、Google
    等,你甚至可以攒个自己的,按下不表;
  • StyleLint,同样插件式架构的样式检查工具,不过我在配置其检查
    react-native

    styled-components
    组件样式时确实费了不小的功夫,可以单独写篇文章了;
  • TSLint:TypeScript
    目前不是我的主要编程语言,但也早早的准备好了;
  • MarkdownLint:Markdown
    如果不合法,可能在某些场合导致解析器异常,因为 Markdown
    有好几套标准,在不同标准间部分语法支持可能是不兼容的;

除上面列的 Lint 工具之外,非常值得拥有的还有
EditorConfig
插件,几乎所有主流 IDE
都有支持,我们可以通过简单的配置文件在不同团队成员、不同
IDE、不同平台下约定好文件的缩进方式、编码格式,避免出现混乱,下面是我常用的配置:

[*]
end_of_line = lf
charset = utf-8
trim_trailing_whitespace = false
insert_final_newline = true
indent_style = space
indent_size = 2

[{*.yml,*.json}]
indent_style = space
indent_size = 2

有了风格检查,自然就会产生按配置好的风格规则做文件格式化的需求,格式化的工具试用了好多,现在还在用的如下:

  • Prettier,实际上已经是代码格式化的工具标准,支持格式化几乎所有的前端代码,并且类似于
    EditorConfig 支持用文件来配置格式规则;
  • Vetur,格式化
    .vue 文件,包括里面的 CSS、JS,至于模板即 HTML
    部分,官方维护者说没有比较好的工具支持,默认是不格式化的;

部分 ESLint 团队中的成员,在过去一直致力于提高和 TypeScript
的相容性,主要进行维护 TypeScript 解析器的工作,虽然这个解析器过去并非由
ESLint 团队维护,但最近落到了团队成员手中,而在 TypeScript 决定转而使用
ESLint 之后,官方认为,Typescript 解析器势必成为发展核心。

自定义规则

显然,ESLint
内置的规则不可能包罗所有需求。可以通过插件实现自定义规则,这是 ESLint
最有卖点的功能。在 NPM
上以 eslintplugin 为关键词,可以搜索到很多插件,包括 eslint-plugin-react。如果有自行开发插件的需求,可以阅读 ESLint
插件开发文档。

以 eslint-plugin-react 为例,安装以后,需要在 ESLint
配置中开启插件,其中 eslint-plugin- 前缀可以省略:

{
  "plugins": [
      "react"
  ]
}

 

接下来开启 ESLint JSX 支持(ESLint 内置选项):

{
  "ecmaFeatures": {
    "jsx": true
  }
}

 

然后就可以配置插件提供的规则了:

 {
  "rules": {
    "react/display-name": 1,
    "react/jsx-boolean-value": 1
  }
}

 

自定义规则都是以插件名称为命名空间的。

编码效率

说到编码效率,连续六年几乎每天都编码的我目前最大的感受是:击键的速度越来越跟不上思维的速度,这种情况下,就需要在编码时设置适当的快捷键,组合使用智能建议、代码片段、自动补全来达到速度的最大化。

VSCode
内置的智能建议已经非常强大,不过我对默认的配置做了如下修改,以达到类似于在
Vim 中那样在任何地方都启用智能提示(尤其是注释和字符串里面):

{
  "editor.quickSuggestions": {
    "other": true,
    "comments": true,
    "strings": true
  },
}

接下来,重点说说代码片段和自动补全两个效率提升利器。

因此 ESLint 官方宣布发布 typescript-eslint 专案,这项工作交由 ESLint
团队的 James Henry 进行维护,Henry 本身便负责长期推动 ESLint 与
TypeScript 相容性,原本的 TypeScript
解析器也将搬迁至集中储存库。官方提到,ESLint
团队并不会正式参与新专案,但会支援 James Henry
并维持畅通的沟通管道,确保为 TypeScript 开发人员提供良好的使用体验。

结语

至此,ESLint 使用入门就介绍完了。但是,我们不应该仅仅是使用 ESLint
这个工具,更应该学习 ESLint
背后的设计理念:不求大而全,但求搭好扎实的基础架构,提供良好的、可扩展的
API。小到插件,大到应用程序开发,这一原则都适用。

由此,很容易让我联想到 WordPress —— 不用修变源代码,通过 hook、filter
机制实现前台、后台所有功能的定制、扩展,其成功离不开这一特性。

Coding 之外,《罗辑思维》所倡导的「U
盘化生存」(自带信息,不装系统,随时插拔,自由协作)不也是这样一种理念吗?不是我不明白,这世界变化快。经验固然有用,但在日新月异的技术潮流中,学习、适应能力更为重要。

代码片段

英文叫做
Snippets,市面上主流的编辑器也都支持,其基本思想就是把常见的代码模式抽出来,通过
2~3 个键就能展开 N
行代码,代码片段的积累一方面是根据个人习惯,另一方面是学习社区里面积累出来的好的编码模式,如果觉得不适合你,可以改(找个现有的插件依葫芦画瓢),我常用的代码片段插件如下:

  • HTML
    Snippets,各种
    HTML 标签片段,如果你 Emmet 玩的熟,完全可以忽略这个;
  • Javascript (ES6) Code
    Snippets,常用的类声明、ES
    模块声明、CMD 模块导入等,支持的缩写不下 20 种;
  • Javascript Patterns
    Snippets,常见的编码模式,比如
    IIFE、;

接下来 ESLint 团队将不再继续维护
typescript-eslint-parser,他们会封存储存库,也不会在 Npm 发布
typescript-eslint-parser,原本使用 typescript-eslint-parser
的开发者应使用 typescript-eslint/ parser 替代。

自动补全

自动补全本质上和代码片段类似,不过是在特殊场合下以你的键入做为启发式信息提供最有可能要输入的建议,我常用的自动补全工具有:

  • Auto Close
    Tag,适用于
    JSX、Vue、HTML,在打开标签并且键入 </
    的时候,能自动补全要闭合的标签;
  • Auto Rename
    Tag,适用于
    JSX、Vue、HTML,在修改标签名时,能在你修改开始(结束)标签的时候修改对应的结束(开始)标签,帮你减少
    50% 的击键;
  • Path
    Intellisense,文件路径补全,在你用任何方式引入文件系统中的路径时提供智能提示和自动完成;
  • NPM
    Intellisense,NPM
    依赖补全,在你引入任何 node_modules
    里面的依赖包时提供智能提示和自动完成;
  • IntelliSense for CSS class
    names,CSS
    类名补全,会自动扫描整个项目里面的 CSS
    类名并在你输入类名时做智能提示;
  • Emmet,以前叫做 Zen
    Coding,我发现后,也是爱不释手,可以把类 CSS 选择符的字符串展开成
    HTML 标签,VSCode
    已经内置,官方介绍文档参见,你需要做的就是熟悉他的语法,并勤加练习;

当然,如果你还用 VSCode 编写其他语言的代码,比如 PHP,就去市场上搜索
“PHP Intellisense” 好了。

(文/开源中国)    

功能增强

在效率提升方面除了上面的代码片段、自动补全之外,我还安装了下面几个插件,方便快速的浏览和理解代码,并且在不同项目之间切换。

  • Color
    Highlight,识别代码中的颜色,包括各种颜色格式;
  • Bracket Pair
    Colorizer,识别代码中的各种括号,并且标记上不同的颜色,方便你扫视到匹配的括号,在括号使用非常多的情况下能环节眼部压力,编辑器快捷键固然好用,但是在临近嵌套多的情况下却有些力不从心;
  • Project
    Manager,项目管理,让我们方便的在命令面板中切换项目文件夹,当然,你也可以直接打开包含多个项目的父级文件夹,但这样可能会让
    VSCode 变慢;

结语

说了这么多,相信读到这里的你也期望用工具来提高自己的效率。

提高效率有没有法门?是有的,简单的事情重复化,重复的事情标准化,标准的事情自动化,发现一个痛点,用插件解决一个痛点,你的效率自然就上来了。

你都用了哪些插件呢?欢迎留言交流!

题外话

就用上面列出来的 VSCode 配置我录制了 3
门前端短视频教程,你能在这些教程里看到我 VSCode
的实操效果,如果你有兴趣,欢迎点击下面链接:

  • 与时俱进:React 16
    新特性尝鲜教程,6
    小节,18 分钟,用实例演示如何运用新特性提高代码稳定性,优化设计;
  • 组件化必杀技:styled-components
    简明教程,8
    小节,23 分钟,让你快速入门现象级的 CSS-IN-JS 解决方案;
  • 玩转异步JS:async/await
    简明教程,8
    小节,20 分钟,通过实战让你把 async/await 用的飞起;

另外,以后每周会放出新的短视频教程,如果你想接到推送,欢迎关注《前端周刊》微信公众号:fullstackacademy,关注即得高清视频云盘地址。