KAITIAN IDE 是如何构建扩展能力极强的插件体系的？
VS Code 自 2015 年推出以来，由于其优越的性能表现和简洁的 UI 设计，迅速得到了开发者的青睐，特别是人数众多的前端开发者。究其原因，是因为 VS Code 优秀的插件架构，通过多进程的模型隔离了插件运行环境，插件进程无法影响主进程的运行效率，这也使得 VS Code 有良好的稳定性表现。
今年下半年，有幸参与了开天 IDE 共建项目组, 打造阿里生态体系内的公共 IDE 底层。插件生态是其中最为重要的一环，能够无缝继承 VS Code 的插件生态对开天 IDE 来说非常重要的一部分。本文简要阐述了 VS Code 插件模型，从实际场景出发在这套体系之上初步构建出开天特有的插件扩展能力。
从图中可以看出，VS Code 插件系统是由一个 Node.js 进程管理插件的启停及生命周期，插件进程与主进程之间是通过进程间 RPC 通信来实现插件逻辑相关调用。
编写过 VS Code 插件的同学一定知道，VS Code 插件必须要引入一个名为 vscode 的模块，这个模块只是一份 VS Code 插件 API 的类型声明文件，而插件进程在启动时由 host 进程负责 API 注入。VS Code 会劫持默认 require 的行为，针对名为 vscode 的模块会返回一个定义好的对象。
// VS Code 插件进程源码function defineAPI(factory: IExtensionApiFactory, extensionPaths: TernarySearchTree<IExtensionDescription>, extensionRegistry: ExtensionDescriptionRegistry): void {// each extension is meant to get its own api implementationconst extApiImpl = new Map<string, typeof vscode>();let defaultApiImpl: typeof vscode;// 已被全局劫持过的 requireconst node_module = <any>require.__$__nodeRequire('module');const original = node_module._load;// 重写 Module.prototype._load 方法node_module._load = function load(request: string, parent: any, isMain: any) {// 模块名不是 vscode 调用原方法返回模块if (request !== 'vscode') {return original.apply(this, arguments);}// 这里会为每一个插件生成一份独立的 APIconst ext = extensionPaths.findSubstr(URI.file(parent.filename).fsPath);if (ext) {let apiImpl = extApiImpl.get(ext.id);if (!apiImpl) {// factory 函数会返回所有 APIapiImpl = factory(ext, extensionRegistry);extApiImpl.set(ext.id, apiImpl);}return apiImpl;}/* 省略部分代码 */}}
运行时由插件 host 进程加载插件模块，并传入 context 参数：
// 插件进程伪代码const extModule = require('path/to/extension.js');const extContext = createVSCodeExtensionContext();const result = await extModule.activate(extContext
VS Code 经过多年的迭代, 插件系统已经非常成熟, 有句话说站在巨人的肩膀上才能看得更远。事实上社区已经有许多兼容(类似) VS Code 插件系统的 IDE，譬如很多同学熟悉的 Eclipse Theia，以及 Vim 党 veonim (Neovim)。甚至还有国人开发的以 VS Code LSP 协议为基础，针对 Neovim 提供跨语言一致补全体验的 coc.nvim。
开天 IDE 天然兼容 VSCode 插件系统。实现层面，我们可以将 vscode 模块当成一份协议，在前端实现 vscode 模块的 API，提供给插件一样的接口与调用行为。在云端环境下，IDE 的服务端会运行在一个容器或者服务器上，前端通过 WebSocket 连接到服务端，而服务端的插件逻辑和上面基本一致，插件在调用相关的 API 时，服务端会转发消息到前端完成一次调用。
虽然 VS Code 插件系统已经足够完善，但其 UI 定制能力非常薄弱，主界面仅提供了少量的按钮与菜单支持自定义。但很多实际场景都有非常强烈的 UI 需求以满足不同的业务能力。一些公司基于开源 IDE 或是自研的方案来实现 UI 定制，在这个前提下，仅仅兼容 VS Code 已有插件显然无法满足这些需求。例如支付宝小程序和微信小程序等 IDE 主界面都需要大量的按钮菜单注入以及模拟器等预览面板。虽然 VS Code 提供的一些功能如 QuickPick，Webview 等可以满足这些需求，但 QuickPick 略微繁琐的交互体验以及 Webview 的展现形式都令人如鲠在喉。
微信开发者工具
支付宝小程序 IDE
针对这些需求我们对插件系统做了更多的扩展，除了 Node.js 的插件运行时，开天 IDE 还支持工具栏，左右侧面板，以及底部面板的 React 组件注入。
在这个基础上，有几个可选的方案来实现 UI 定制。
组件注入
IDE 通过暴露注入点的方式提供 UI 插槽，插件需要提供 browser 模块，调用 API 并指定注入位置等信息。
// Componentexport const ToolBarComponent = (props) => {props.service.alert('hello world.');return (<button>click me.</button>);}// configexport default {toolBar: {position: POSITION.LEFT,component: ToolBarComponent,}}
扩展插槽可以以 DOM 节点的方式提供，但其 UI 风格较难统一，由于是开发者自行编写的组件，可能由于部门及业务差异，组件样式风格差异较大。另外在组件调用 Node 模块提供的 Services 时，onClick 等事件对象会作为参数传递给对应方法，但由于是 RPC 调用，无法对这一类参数进行序列化，需要将 Services 方法做一次包装，调用方要显式的传递需要的参数过去。
扩展点提供者与消费者
这种方案不直接注入组件，转为由特定的一类插件实现一组插槽，可以自定 API 和参数，普通插件可以作为插槽消费者。例如 ToolBar 部分，A 插件声明为一个插槽容器，提供一组 API，其它组件调用其 API 注册按钮等部件。IDE 需要实现插件之间互相访问的能力，同时对插槽提供者做特定区分。其中普通插件无法对样式做修改，容器插件应该提供一些特定的组件，普通插件需要注册 Command 或者以传入回调函数的方式处理相关的事件。容器插件应该有较大的 UI 自由度，可以提供 browser 模块声明插槽位置，同时应该有内置的如按钮，输入框等基本组件。
容器插件：
// 容器插件 browserimport * as kaitian from 'kaitian';import { ButtonBasic, InputBasic } from './components';kaitian.registerSlotContainer({position: kaitian.POSITION.LEFT,container: Slot,components: [{type: 'input-basic',contributions: [{name: 'onchange',type: 'function',},{name: 'icon',type: 'string',},{name: 'label',type: 'string',},{name: 'position',type: 'number',}],component: InputBasic,},{type: 'button-basic',contributions: [{name: 'onclick',type: 'function',},{name: 'icon',type: 'string',},{name: 'label',type: 'string',},{name: 'position',type: 'number',}],component: ButtonBasic,}]});// 组件容器class Slot extends React.Component {registerComponents(configs) {this.componentMaps = configs;}componentDidMount() {const {kaitianExtendSet} = this.props;if (kaitianExtendSet) {// 给 node 模块调用kaitianExtendSet.set({registerComponents: this.registerComponents,});}}render(){return (<div>{this.componentMaps.map((com) => {const Component = components.get(com.type);<Component icon={com.icon} label={com.label} handler={(...args) => props.kaitianExtendService.eventHandler(id, ...args)} />})}</div>);}}// 容器插件 nodeexport function activate(context) {const { componentProxy, registerExtendModuleService } = context;const eventHandlerMap = new Map();return {registerComponents: (configs) => {const serializeConfig = configs.map((config) => {if(config.type === 'button-basic') {const id = randomId();// 事件回调放在 node 层，UI 事件只发 id 和 args到 node 层。eventHandlerMap.set(id, config.onclick);return {...config, onclick: id};}// ...});componentProxy.container.registerComponents(configs);},eventHandler: (id, ...args) => {const handler = eventHandlerMap.get(id);handler(...args);};}}
消费者插件：
// nodeimport * as kaitian from 'kaitian';function activate(context) {const container = kaitian.getSlotContainer('basic-slot-container');contaier.activate(context);.then((registry) => {registry.registerComponents([{type: 'button-basic',onclick: (args) => {kaitian.window.showInformationMessage('Hello World');// ...},icon: 'basic btn',label: '按钮',position: 0,}]);})}
容器插件提供的组件和 API 需要一定的通用性，理想情况下应该是以业务方一个小组为基本单元，编写自有的容器插件，其余业务插件通过调用容器插件注册的方式实现 UI 自定义。实现上这种方案略微复杂，对容器插件开发者和使用者来说都有一定的学习成本，API 设计需要尽可能简洁易懂。
这种方案只需要容器插件提供 UI 层面一些基础的组件模板，消费者插件不需要编写 UI 代码(browser 模块)，完全运行在 Node.js 进程中，相比之下安全性和稳定性更高，而且基于容器插件的能力，可以针对各种业务形态定制不同风格的 UI 样式，统一插件的风格。
这两种方案各有优劣，在目前版本的开天 IDE 中都可以实现，一般情况下具有独立功能与 UI 的插件推荐使用第一种方式直接注入组件，而一些需要多个插件组合的复杂场景下，建议使用容器/消费者的方式，减小 UI 部分代码的重复工作量，统一风格。基于容器/消费者的插件 UI 定制方案目前已经在内部场景中上线探索并验证。
工具的价值体现在是否能一定程度上解决问题从而提升工作效率，在这条路上我们才刚刚开始，还有许多未知的挑战在等着我们。我们希望能以 IDE 为基础打通研发体系，实现真正的全链路云端开发。
你可能还喜欢👇👇
关注「Alibaba F2E」
把握阿里巴巴前端新动向