VSCode For Web 深入浅出 -- 插件加载机制

最近我在浏览 VSCode for web 的 repo，在最近更新的一些 commit 中发现了一个新的 VSCode 插件特性支持，名为 webOpener，它的作用是什么呢？又是如何影响插件加载的呢？在这一篇中我们结合 VSCode For Web 的插件加载机制来详细分析一下。

---

VSCode for web 的插件加载机制

我们知道，由于 VSCode for web 运行在浏览器上，因此，它的插件加载机制与 VSCode for desktop 有所不同。

在 VSCode for desktop 中，插件是以 vsix 包的形式存在的，因此，VSCode for desktop 可以直接通过 vsix 包的形式加载插件。而在 VSCode for web 中，由于浏览器的安全机制，不能直接加载 vsix 包。

因此，VSCode for web 采用了一种特殊的插件加载机制。发布 VSCode for web 插件时，发布系统会直接将项目编译，并发布到 CDN 节点上。当用户加载插件时，通过向该目标 url 发送请求，拉取远端（也可以是本地）的 extension.js 文件。并利用 web worker 加载机制，为每个插件分配独立线程加载与执行。

在生产环境中，对每个进入 VSCode 插件商店的插件，VSCode for web 会将支持 web 环境的插件的 package.json 与 extension.js 等文件打包成一个 zip 包，然后根据 publisher 分配合适的二级域名，通过 CDN 分发。

以我在使用的One Dark Pro主题为例：

而在调试模式中，我们可以通过 Install extension from location...命令，指定编译后插件的 url，从而加载插件。

我们使用本地服务器，指定一个已编译好的 VSCode web extension，并填入本地服务器地址 (https://localhost:5000)，并刷新页面，那么从 Chrome 的 Network 中可以看到 VSCode 向目标位置请求了package.json 与 extension.js，并看到插件已经被成功加载了。

通过这样的方式，VSCode for web 在每次页面打开后，完成了对用户自定义的插件管理与加载。并由于web worker的特性，每个插件的执行环境都是独立且相互隔离的。

通过特殊 url 路由的方式的插件加载机制

VSCode for web 最突出的特点是它是运行在浏览器上的，因此，我们可以利用 url，来实现一些奇妙的新特性。例如，通过特殊的 url 路由，免安装地加载插件。

目前，vs