你的VS Code拓展很慢？教你怎么让它提速

- Extensions Rock -

VS Code用户（我们中的很多人）非常喜欢我们的拓展，有数千个VS Code拓展可选，而且我们中很多人都安装了一些。它们照亮了你喜爱的编程语言，格式化代码，或者让你的主题更加地多彩。

你是否意识到，有一些拓展在VS Code启动之后，需要花费几分钟来初始化？是什么引起的这种延迟？

关于这个问题，你能做点什么？事实上，你可以做很多。跟我一起来看看你可以为喜爱的拓展更快地加载做些什么。

一个可能的原因，是文件的数量和拓展的大小。一些拓展里面有非常多的功能，这些功能会随着时间让拓展越来越慢。

等等，为什么是这样

当我们为web构建app时，我们写了几十个或数百个JavaScript，CSS 和 HTML文件。我们不想通过网络向一个浏览器发送一千个文件，因为这样的体验很差，会一直等待着加载。当我们没有尽可能地让我们写的代码针对浏览器进行优化，体验也很差。现代化的工具通过将多个文件压缩成一个（或一个小集合）文件来帮我们解决这个问题，一个流行的工具叫WebPack。

如果你使用命令“Developer: Show Running Extensions”，你讲看到你的VS Code实例中一个被激活的拓展的列表。在列表的右侧，你也将看到每个拓展要激活所需要的毫秒数。

这是发现哪个拓展激活缓慢的非常好的一个方法。注意看下面我的VS Code中安装的拓展，和它们的激活时间。明显地，一些拓展比其它拓展耗费更长的时间来加载，因为它们做的事情更多。

如果一个拓展耗费更长的时间，你可以做什么？（可能1000ms？）

让拓展更快

最近，VS Code团队发布了一个使用WebPack来打包拓展的文件的功能。

这篇文章真的涵盖了所有，在打包一个拓展的时候是有帮助的。

我发现我的拓展Peacock将48个文件打包到一个包里。我做了一些调整，我把这个削减了很多。

首先，我将一些文件添加到.vscodeignore文件中。

# Files I excluded
azure-pipelines.yml
ISSUE_TEMPLATE.md
PULL_REQUEST_TEMPLATE.md
vsc-extension-quickstart.md
node_modules/**/test/**

# After webpack, we have more to ignore
node_modules
out/
src/
tsconfig.json
webpack.config.json

然后，我为我的拓展创建了一个新的分支，我查阅了VS Code文档中步骤，使用WebPack更新了我的项目。

我的目标是让下面这些仍然能工作：

使用 npm run package 打包
使用 npm run publish 发布
使用 npm run test 做本地CI测试
使用F5和 launch.json 调试
使用F5和 launch.json 调试测试

这种方法让我用Webpack和TSC编译测试和调试。

这是我的项目：https://github.com/johnpapa/vscode-peacock

改变package.json中的main文件：

"main": "./dist/extension",

package.json 中的npm scripts：

"scripts": {
  "package": "npx vsce package",
  "publish": "npx vsce publish",

  "vscode:prepublish": "webpack --mode production",
  "compile": "webpack --mode none",
  "watch": "webpack --mode none --watch",

  "postinstall": "node node_modules/vscode/bin/install",
  "just-test": "node node_modules/vscode/bin/test",
  "test-compile": "tsc -p ./ && npm run compile",
  "test": "npm run test-compile && node node_modules/vscode/bin/test"
},

launch.json中调试运行和测试的configurations：

"configurations": [
  {
    "name": "Run Extension",
    "type": "extensionHost",
    "request": "launch",
    "runtimeExecutable": "${execPath}",
    "args": ["--extensionDevelopmentPath=${workspaceFolder}"],
    "outFiles": ["${workspaceFolder}/dist/**/*.js"],
    "preLaunchTask": "npm: test-compile"
  },
  {
    "name": "Extension Tests",
    "type": "extensionHost",
    "request": "launch",
    "runtimeExecutable": "${execPath}",
    "args": [
      "${workspaceFolder}/testworkspace",
      "--disable-extensions",
      "--extensionDevelopmentPath=${workspaceFolder}",
      "--extensionTestsPath=${workspaceFolder}/out/test"
    ],
    "outFiles": ["${workspaceFolder}/out/test/**/*.js"],
    "preLaunchTask": "npm: test-compile"
  }
]

下面这整个repo里你可以看到上下文中说到的任何东西👇

https://github.com/johnpapa/vscode-peacock

它能有什么影响？

这是一个很好的问题，也是一个我们绝对要回到的问题。我的意思是，毕竟，任何代码更改都必须有一定的价值。我可以获得分享一些两个你可能使用过的拓展的性能统计（非官方测试）的权限（感谢VS Code团队和Erich Gamma）。

这两个拓展都有一个非常大量的逻辑在里面，且都做了一些相当让人印象深刻和有用的事情。

Azure Account

Azure Account拓展的大小和文件的数量减少的相当多。。。就像从"我的天"到"还不坏"。

热激活是一个术语，表示拓展之前已经安装过了（不是第一次）还需要多久才能启动。这个拓展的热激活被砍了一半，总之不算太坏。

下载大小(.vsix)：6.2M到840K
打包文件数：4300到11
热激活时间：676ms到338ms

Docker

Docker拓展有一个值得注意的是，热激活提升到2秒内。但是，关键的方面是冷激活时间。领激活是拓展被安装时需要多少时间来激活。

热激活时间：3.5s到小于2s
冷激活时间(第一次安装之后)：20s到2s

Tips

一些事情受使用webpack来打包一个拓展的影响。这就是为什么测试所有这些非常重要。

在你的调试中本地运行这个拓展(并且测试你可以打断点)
打包这个拓展，并从菜单中加载它(从VSIX加载)
用debugger来运行你的测试(而且，你可以打断点测试)
从 npm test 来运行你的测试脚本

但是，我不写拓展

没事，但是如果你喜欢拓展，考虑为它的仓库创建一个pull request(PR)来启用webpack打包。

关于OSS很棒的一点，是每个人都有发言权，这是一个很棒的方式来帮你喜欢的项目和你的同事。