这篇文章可能会得罪一部分 VSCode 扩展的作者，但是我实在是看不惯网上很多的文章还在推荐一些已经过时的扩展，我觉得作为 VSCode 的老粉，我有必要写一篇文章科普一下。

在 VSCode 扩展市场目前其实存在着不少下载量特别高但是不应该再被使用的扩展，显然官方是不可能直接给你标出来哪些扩展已经被废弃了，哪些有严重 bug，纯靠扩展作者自觉。很多人新人由于没有深入去了解过，看了一些文章的介绍或者看了扩展市场的简介觉得有用就安装了，其实 VSCode 扩展安装多了会导致不少问题的：

1. 启动慢，很多扩展是启动 VSCode 的时候就开始加载的，所以不一定是 VSCode 自身变慢了，可能是你扩展状多了
2. 扩展之间打架，比如安装了多个会修改代码颜色的扩展，TODO highlight 和 Todo Tree 之间
3. 功能重复，例如：IntelliSense for CSS class names in HTML 和 HTML CSS Support
4. CPU 占用过高，很多被弃坑的 VSCode 扩展你去看它们 github 主页都可以看到一堆 issues 抱怨这个问题，例如 import-cost

本文将主要从两个角度介绍一些不推荐使用的 VSCode 扩展：

1. 功能已经被 VSCode 内置
2. 维护不积极的扩展

本文只是给出一些你应该考虑卸载的理由，不是劝说你就应该卸载它们，但是我觉得这些事情你应该清楚。

功能已经被 VSCode 内置

Path Intellisense

Last updated：2016/4/17 下午 2:06:10

Issues open/close: 72/60

Download: 2.7M

我经常看到一些使用 VSCode 没几天的人喷 VSCode 没有路径补全，我觉得很莫名其妙。可以看到这个扩展已经快 4 年没维护了，这也是一个应该放弃使用它的理由，其实如果一个工具本身功能完善，没什么 bug，没有依赖别的项目的话，长期不更新倒没什么。但实际上很多项目都会依赖别的项目，尤其是使用 JS 开发的 VSCode 扩展，经常可以看到各种 npm 包报安全漏洞，最近一次影响比较大的应该是 acorn。

其实 VSCode 自身已经支持在 import/require 也就是导入语句中使用路径补全，但是在其它场景中写路径字符串时还是没有提示。如果你觉得在导入语句中有路径补全已经能够满足你的使用需求，那我觉得这个插件可以考虑卸载了。类似的还有 Path Autocomplete。

Auto Close Tag

Last updated: 2018/2/17 下午 3:24:33

Issues open/close: 100/59

Download: 2.7M

从侧边栏可以看到我一个扩展都没打开。

Auto Rename Tag

Last updated: 2019/10/27 下午 5:57:53

Issues open/close: 452/71

Download: 2.7M

直接使用 F2 重构即可，不需要安装扩展。auto close tag 和 auto rename tag 的扩展包 Auto Complete Tag 也可以考虑卸载了。

npm Intellisense

Last updated: 2017/2/23 上午 4:56:50

Issues open/close: 27/19

Download: 1.9M

这个扩展的功能是支持在导入语句中提供 npm 模块补全，从最后更新时间来推测这个功能应该 3 年前就被内置支持，但是下载量很恐怖啊，github 上还能看到 9 天前提的 issue，人间迷惑行为。

Document This

Last updated: 2019/4/17 下午 6:42:11

Issues open/close: 64/123

Download: 638K

VSCode 已经内置生成 jsdoc 的功能。

HTML Snippets

Last updated: 2019/4/17 下午 6:42:11

Issues open/close: 19/21

Download: 3.2M

这个扩展的下载量充分说明了有些人安装扩展只看名字。

TypeScript 相关

扩展市场里面搜索 TypeScrip，勾选按照安装数量排序，前面几个最流行的扩展的功能基本上全部已经被 VSCode 内置，VSCode 自身就是使用 TypeScript 编写的，TypeScript 相关实用特性开发排期的优先级必然很高。所以 Auto Import, TypeScript Hero, TypeScript Importer, Move TS 都可以考虑卸载了。安装量最高的 auto import 下载量高达 867K，最少的都有 250 多 K。

维护不积极

Color Highlight

Last updated: 2017/7/12 上午 12:19:21

Issues open/close: 49/25

Download: 877K

可以考虑 vscode-colorize 作为替代品。

TODO Highlight

Last updated: 2018/7/22 下午 6:15:54

Issues open/close: 27/19

Download: 1.9M

推荐替代品 Todo Tree，下面是我配置了 TODO 注释高亮后使用效果：

推荐配置：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

"todo-tree.general.tags": ["TODO:", "FIXME:"],
"todo-tree.highlights.defaultHighlight": {
    "gutterIcon": true
},
"todo-tree.highlights.customHighlight": {
    "TODO:": {
        "foreground": "#fff",
        "background": "#ffbd2a",
        "iconColour": "#ffbd2a"
    },
    "FIXME:": {
        "foreground": "#fff",
        "background": "#f06292",
        "icon": "flame",
        "iconColour": "#f06292"
    }
}

Live Server

Last updated: 2019/4/17 下午 6:42:11

Issues open/close: 323/324

Download: 4.7M

live server 确实是个好东西，能让你修改 HTML 代码时自动刷新网页，最主要的是它是以真实的服务器托管的网页，而不是像我们直接用浏览器打开文件时是使用 file:// 协议托管的，更贴近实际生产环境，file:// 协议还会导致跨域等问题。

这个扩展其实从更新时间上来看也不算太长没更新，主要是你去它的 github issue 页面 一看，有很多和性能相关的 issues，这个扩展的作者自己在扩展市场的主页也置顶说了在找人维护这个项目。

Bracket Pair Colorizer 2

Last updated: 2019/7/16 下午 12:03:57

Issues open/close: 184/35

Download: 756K

进 github issues 页面 看，一堆 issues 没人理，和很多不维护的扩展一样，最多的就是导致 CPU 占用过高的问题。

import-cost

Last updated: 2018/11/30 上午 1:55:09

Issues open/close: 32/44

Download: 517K

import-cost 是 wix 开源项目下的 VSCode 扩展之一，另一个下载量比较高的扩展是 glean。想当初我刚入坑 VSCode 的时候这是当时被安利率最高的扩展之一。和前面说的几个扩展一样，有 CPU 占用过高的 issues，没人维护了。

Output Colorizer

Last updated: 2017/7/6 上午 2:13:49

Issues open/close: 10/13

Download: 517K

冲这最后更新时间我也不敢用了啊，从 issues 来看都说这个扩展的功能已经失效。

SVG Viewer

Last updated: 2019/2/28 下午 5:37:42

Issues open/close: 20/20

Download: 427K

推荐国人开发的替代品：vscode-svg2，对比这俩项目的 github issues 形成下鲜明的对比啊，这个国人明显维护更加积极，功能也更全，更强大。

Regex Previewer

Last updated: 2018/4/27 下午 10:47:11

Issues open/close: 23/13

Download: 169K

推荐在线工具 regex101。

其它一些不推荐使用的扩展

TSLint

如果你还不知道 tslint 去年年初就被废弃了，并且现在是以插件的形式被集成到 ESLint 了，我觉得你可能是个假前端。

Beautify

VSCode 内置的格式化器就是使用 js-beautify，但是前端界当前最流行的格式化工具是 prettier，建议安装 prettier，然后设置 VSCode 使用 prettier 作为格式化器：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

// settings.json
"[javascript]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[javascriptreact]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[typescript]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[typescriptreact]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[json]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[vue]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[html]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[css]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[less]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[scss]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[markdown]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[yaml]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
}

jshint

就没见几个开源项目还在用 jshint，推荐使用 vscode-eslint。

如何推荐别人使用一些扩展

我们可以在项目根目录的 .vscode/extensions.json 文件中配置一些推荐和不推荐使用的扩展，在扩展市场选择 Show Recommended Extensions 就可以看到我们推荐的扩展。

1
2
3
4
5
6
7
8
9
10
11

// .vscode/extensions.json
{
  "recommendations": [
    "editorconfig.editorconfig",
    "dbaeumer.vscode-eslint",
    "esbenp.prettier-vscode",
    "yutengjing.view-github-repository",
    "yutengjing.open-in-external-app"
  ],
  "unwantedRecommendations": ["hookyqr.beautify", "ms-vscode.vscode-typescript-tslint-plugin", "dbaeumer.jshint"]
}

最后

貌似 VSCode 最近几个月一直都在做设置同步的功能，也就是 Settings Sync 做的事情，估计正式上线后这个扩展也可以考虑卸载了。以前写过推荐 VSCode 扩展的文章，那时我安装的扩展有 100 多个，现在也就将近 50 个左右，是越来越挑剔了，我自己也写了两个简单的扩展 View GitHub Repository 和 Open in External App，之前开发扩展后还提炼了一个 VSCode 扩展开发模板：vscode-extension-boilerplate，感兴趣的读者可以了解下。

最后奉上我的 VSCode 扩展 gist 地址：cloudSettings，可以搭配 Settings Sync 使用。

本篇为 从零开始配置 react + typescript 系列第三篇，将带大家完成模板项目的 webpack 配置。整个项目的配置我力求达到以下目标：

灵活： 我在配置 eslint 是选择使用 js 格式而不是 json，就是为了灵活性，使用 js 文件可以让你使用导入其它模块，根据开发环境动态配置，充分发挥 js 语言的能力。

新潮： 我觉得时刻保持对新事物的关注和尝试去使用它是一个优秀的素质。当然，追新很容易碰到坑，但是，没关系，我已经帮你们踩过了，踩不过去我也不会写出来 😂。从我 eslint parserOptions.ecmaVersion 设置为 2020， 还有经常来一发 yarn upgrade --latest 都可以体现出来。

严格： 就像我平时判断相等性我大多数情况都是使用严格等 ===，而不是非严格等 ==，我觉得越严格，分析起来就越清晰，越早能发现问题。例如我么后面会使用一些 webpack 插件来严格检查模块大小写，检查是否有循环依赖。

安逸： 项目中会尽量集成当前前端生态界实用的和能提高开发愉悦性的（换个词就是花里胡哨）工具。

生产 ready：配置的时候针对不同的打包环境针对性优化，并确保能够投入生产环境使用。

本篇将分三大部分介绍：

1. dev server
2. 开发环境优化
3. 生产环境优化

如果读者是初次看到这篇文章，建议先看下前两篇：

1. 从零开始配置 react + typescript（一）：dotfiles
2. 从零开始配置 react + typescript（二）：linters 和 formatter

项目地址：react-typescript-boilerplate

继 从零开始配置 react + typescript（一）：dotfiles 介绍了一些最先配置的 dotfiles，本篇将继续介绍 lint 工具 eslint，stylelint，代码格式化工具 prettier，用 husky + lint-staged 来实现每次 commit 时只 lint 修改过的代码，以及使用 commitlint 来规范化 commit message。

项目地址：react-typescript-boilerplate

之前我写过一篇文章 搭建 react + typescript + ant design 开发环境，现在看来很多内容都已经过时了。但是我看到前不久还有读者给我这篇文章点赞，不更新的话总感觉坑了它们，有点过意不去。但是，如果现在让我再去配置那套环境，我肯定不会再像那篇文章那样配置了，毕竟过了这么长一段时间，很多工具都在发展，我的想法也在改变，那么干脆我就再整一篇新的文章，这是我创作这篇文章的动机之一。

最近一段时间，我写过不少类型的项目，有 chrome 扩展，VSCode 扩展， electron 等，配置开发环境都是裸写的，并没有使用一些 cli 工具或者第三方的项目模板。因此，我踩过不少坑，也总结了不少的经验。所以另一个创作动机就想总结和分享一下我配置开发环境的最佳实践。

我使用的开发机和编辑器分别是 win10pro-1909 和 VSCode，使用的所有依赖都是最新的，并且文章会不定时更新，确保具有时效性。

文章将按照开发一个模板项目的时间顺序预计分成四篇来写：

1. dotfiles
2. linters 和 formatter
3. webpack
4. 第三方库集成和优化

项目地址：react-typescript-boilerplate

记得以前知乎上看到过一个问题：面试一个 5 年的前端，却连原型链也搞不清楚，满口都是 Vue，React 之类的实现，这样的人该用吗？ 。写文章的时候又回去看了下这个问题，300 多个回答，有很多大佬都回答了这个问题，说明这个问题还是挺受关注的。最近几年，随着 ES6 ，TypeScript 及类似的中间语言的流行，我们平时做业务开发很少能接触到原型，基本上都是用 ES6 class 来去更简单的，更直观的实现以前构造器加原型做的事情。

其实在我看来，我觉得原型链是一个非常重要的基础知识。如果一个人说他 C 语言很精通，但是他汇编不熟，你信吗？我觉得 winter 说的挺简洁到位的：

这又涉及到我之前讲过的面试官技巧，面试，是对一个人的能力系统性评价，搞清楚一个人擅长什么不会什么，所以问知识性问题，为了避免误判，一定要大量问、系统化地问。

不会原型很能说明问题，至少他在库的设计方面会有极大劣势，而且可能学习习惯上是有问题的，也有可能他根本就不太会 JS 语言，但是这不意味着凭借一个问题就可以判定这个人不能用。

本文包括以下内容：

1. JavaScript 原型
2. 构造器和 prototype
3. 原型链
4. 原型的用途
5. ES6 class 和构造器的关系
6. 原型继承
7. JavaScript 和原型相关语法特性
8. 原型污染
9. 补充一道最近校招面试碰到的和原型相关的面试题

前不久我写了一个 chrome 扩展，作为一个前端弄潮儿，我当然想用上各种前端界最 fashion 的开发工具。于是乎，折腾到最后使用了 webpack + TypeScript + react 这么一套技术栈。在 github 上研究了几个模板项目之后，发现大多数都太初级了，功能太简单，而且有一个我觉应当提供的很基础的功能始终没发现有哪个项目支持，也就是当修改了 content script 之后自动 reload 扩展和刷新注入了 content script 的页面这个问题。这个问题如果解决了，你就不需要每次修改了扩展代码还去 chrome 扩展列表页面点下刷新按钮刷新扩展。最后在研究了 webpack 的热更新机制和查阅了 webpack 和 chome 扩展官方文档之后解决了这个问题。在开发完我那个扩展之后，我便将其提取成了一个模板项目 awesome-chrome-extension-boilerplate。

其实我在使用 webpack + TypeScript + react 这套技术栈开发 chrome 扩展时碰到的问题真不少，如果全拿出来讲没个两万字我估计是写不完。这篇文章主要聊聊 webpack 开发 chrome 扩展的热更新问题，并重点讲解我是如何实现修改了 content script 之后自动 reload 扩展和刷新注入了 content script 的页面的，这也是我那个模板的最大特色，也算是给它的 README 做个补充。

在阅读文章之前，希望读者对 webpack 和 chrome 扩展开发有基本的了解。本文的主要内容分为：

1. 我对 chrome 扩展的理解
2. 各种页面的热更新问题分析
3. 如何实现修改了 content script 之后自动 reload 扩展和刷新注入了 content script 的页面

相信到了年底，不少前端都准备找工作跳槽了。而作为春招大军的一员，估计很多准备春招的应届生和我一样这个年过得很焦虑。JavaScript 类型是前端面试中考察 JavaScript 基础的常考知识点，经常性第一个问题就是 JavaScript 中有哪些类型。

笔者今年从春招实习到秋招经历了挺多的面试，也总结了一些规律：一般来讲第一轮面试往往就是考察基础，就算你简历很牛逼那也得走个流程啊。而考察基础一般就按照 HTML，CSS，JavaScript，计算机网络，常见的 web 安全，后端知识如数据库，鉴权，再就是最后来两道算法题或智力题或数学题。

最近几个月我都很少像以前那样一天到晚刷掘金和知乎的文章，基本上就是在开源项目中实战学习，我觉得刚入门前端的人确实需要多看一些优质的博客。刚入门更需要广度，随后是广度和深度并行，最后才是深度。其实说人话就是：刚开始入门时因为没怎么写过项目，懂得太少，所以需要多看，被动吸收。到后来有一定广度了，你会发现其实你在写一个项目的时候往往碰到的问题就是因为你的深度不够，这个时候你会更注重深度。最后当你广度慢慢到了一定程度后，由于网络上 99% 的文章都是小白文，你看了标题之后就大概闻的出文章是啥内容，看了对你也没啥用，这个时候你更因该把时间花在一个小的领域，注重深度，深度才是最能体现一个程序员技术价值的地方。

前面唠叨了一堆废话，下面正式开始本文内容。本文内容主要分两部分：

1. 总结 JavaScript 中各种类型一些值得注意的地方，小技巧和个人心得
2. JavaScript 如何进行类型判断

系统，扎实的 javascript 语言基础是一个优秀的前端工程师必须具备的。在看了一些关于 call，apply，bind 的文章后，我还是打算写下这篇总结，原因有几个。首先，在如今 ES6 大行其道的今天，很多文章中讲述的它们的应用场景其实用 ES6 可以更优雅的解决，但是基本上·没有文章会去提 ES6 的解法。再则，讲它们的实现原理的文章其实不少，但是或多或少实现的有些不够完美，本文将把它们通过代码一一比较完美的实现，让它们不再神秘。不谦虚的说，关于 call，apply，bind 的知识，看这一篇文章就够了。

文章中的源码地址：deep-in-fe

浏览器 HTTP 缓存是一种常见的 web 性能优化的手段，也是在前端面试中经常被考察的一个知识点。本文通过配置 koa2 服务器，在实践中带你探究浏览器的 HTTP 缓存机制。

9102 年了，前端工程化发展在 nodejs 的基础上已经发展的非常完善了，各种前端构建辅助工具层出不穷。ES6 编译器 babel，css 辅助工具 postcss / sass / less，代码风格检测工具 eslint / prettier / stylelint，git 辅助工具 husky / lint-staged / commitizen / commitlint，自动化构建工具 webpack / gulp / grunt，测试工具 jest / mocha 等等。

这么多开发辅助工具每次写项目都去配置一遍那也太浪费时间了，自己维护一套模板有得时不时去更新。比较方便的配置开发环境还是使用 cli 或者一些热门的 bolierplate。本篇文章将以 react 官方维护的 cli 工具 create-react-app （简称 cra）为基础，以不 eject 的方式去配置 ant design，以及一些 cra 并没有内置的辅助工具。