兼容 VS Code 插件！阿里&蚂蚁联合开源国内首个强定制 IDE 研发框架 OpenSumi

官网地址：https://opensumi.com/

OpenSumi 是一款面向垂直领域，低门槛、高性能、高定制性的双端（Web 及 Electron）IDE 研发框架，基于 TypeScript+React 进行编码，实现了包含资源管理器、编辑器、调试、Git 面板、搜索⾯板等核新功能模块。开发者只要基于起步项目进行简单配置，就可以快速搭建属于自己的本地或云端 IDE 产品。

框架自身兼容 VS Code 插件生态，主流 VS Code 插件均可⽆缝在基于 OpenSumi 研发的产品中运行。同时，OpenSumi 为开发者提供了多种低成本、⾼定制的视图定制能力，能满足 IDE 场景下绝大多数视图定制场景。

IDE 产品的研发一直以来都是一件门槛高、费时费力的事情，OpenSumi 项目组希望通过开源 OpenSumi 帮助对 IDE 有兴趣的开发者更好地了解并掌握 IDE 研发这项技术，让更多的开发者可以以一种低门槛的方式去研发自己的 IDE 产品。同时，通过社区中开发者的使用，也可以帮助 OpenSumi 更好地改进，获得更多的需求场景输入，同时通过社区影响力让框架获得更加长远的发展。

由于各种原因，开发者群体中不乏质疑阿里、蚂蚁开源是 KPI 项目的声音，一些项目开源出来后可能很快就消亡了，如何保证 OpenSumi 不会走上同样的道路呢？

为了保证框架可以同时在 Web 和 Electron 环境下运行，OpenSumi 采用了一套前后端分离、通过抽象的通信层进行相互调用的项目结构。

在 Web 上使用 WebSocket 作为通信的实现，在 Electron 上则是 IPC 通信。每一个通信的连接对应前后端一个独立的 DI (Dependence Inject) 容器，所以 OpenSumi 的后端实现是无状态的，不同连接之间严格隔离。

OpenSumi 内主要有三个核心进程：插件进程 （Extension Process）、后端进程 （Node Process）和前端进程 （Browser Process）。

为了保证插件的问题不会影响 IDE 的性能表现，插件能力上 OpenSumi 采用了跟 VS Code 类似的方案，通过独立的插件进程去启动插件，插件进程再通过后端进程与前端进程通信。

OpenSumi 的不同能力实现被拆分到了不同的模块内，这些模块通过 贡献点机制 (Contribution Point)、DI 机制 (Dependence Inject) 互相之间有较弱的依赖关系，对于一些比较核心的基础模块，如主题服务、布局服务等，也会被其他模块直接依赖。因此，在集成开发过程中需要保证一些模块的引入顺序。

整体启动的生命周期如下图所示：

关于 OpenSumi 模块和插件的更多介绍，详见：https://opensumi.com/zh/docs/integrate/overview

目前研发 IDE 的主流框架包括 code-server 和 Theia，在性能和编码体验上 OpenSumi 与主流框架相近，OpenSumi 相较于主流框架的优势主要在于两点，即更强的视图可定制能力、更友好的集成手段和丰富的场景案例。

基于 OpenSumi 的基础框架，开发者可以自由地通过模块或插件定制自己的 IDE 产品，实现真正意义上的“全视图定制”能力。

在许多内部产品实现阶段，会通过模块实现基础能力以得到更好的可维护性，而通过插件实现业务上的视图或能力定制，则可以实现更好的定制性。以阿里内部的部分研发场景为例，结构分层如下：

另外，OpenSumi 在设计之初就确定要兼容 VS Code 插件生态，因此对框架会有持续性的要求，开源后团队计划每三个月完成⼀次 VS Code 插件 API 的适配⼯作，适配计划的制定将会由相应的版本管理⼈员组织在讨论区进⾏，当前已适配⾄ VS Code v1.60.0 版本标准 API， 进度可⻅适配计划。相比之下，Theia 框架虽然兼容了一部分 VS Code 插件能力，但对于后续 VS Code API 的兼容已经越来越少，基本依赖社区开发者自发贡献。

在应用场景方面，OpenSumi 在正式对外开源之前，已经在阿里集团和蚂蚁集团内部持续孵化超过两年，期间沉淀落地了一系列具有代表意义的垂直领域下的研发案例。因此大部分能想到的研发实践场景，可能都可以在 OpenSumi 中找到实践经验。

按照不同的应用场景划分，下面 OpenSumi 目前的内部应用实践部分案例：

• 在本地客户端场景中，以小程序研发为例，支付宝小程序开发者工具、淘宝小程序开发者工具都使用了 OpenSumi 作为核心框架实现，截至目前，外部月活用户已达到 1.9 W+；

• 在云端研发场景则有阿里云外部的云开发平台、阿里内部的 O2 研发平台、蚂蚁内部的 Ant Codespaces 等，累计月活已达到 2W +；

• 纯前端搭建能⼒是 OpenSumi 在阿⾥及蚂蚁集团内应⽤的最为⼴泛的⼀块能⼒，它提供了⼀种不需要依赖服务端提供编辑器启动所需的 Node.js 服务，而可以直接通过纯前端资源及静态接⼝定义搭建⼀个具备编辑器基本界⾯的能⼒。在纯前端场景中，蚂蚁内部的 AntCode、阿里内部的 O2 CodeReview 平台都是通过 OpenSumi 提供的纯前端能力搭建了代码评审平台，而内部的 Riddle 和 O2 Sandbox 平台则是通过纯前端的能力，搭建了基于前端依赖构建的代码片段分享平台；

• 同时，阿里内部的 Aone IDE 研发中台也能为开发者提供一个无后端环境下可用的研发接口，通过平台上通用的配置，开发者基于前端技术栈就能完成云端 IDE 的研发工作。

开发者面对主流框架和 OpenSumi 该如何选择？OpenSumi 项目组建议，可以先简单了解一下各个框架所能解决的具体需求场景。OpenSumi 的核心优势是视图定制上的能力以及不输于主流框架的编码体验，如果对于视图有较强的定制需求，则可以尝试使用 OpenSumi 进行搭建。同时，对于中文开发者来说，选择 OpenSumi 可以一定程度上减少沟通及集成过程中的障碍，尽情参与到 OpenSumi 后续的开发及讨论之中。

OpenSumi 是由阿⾥集团淘系⼯程团队及蚂蚁集团体验技术部、研发效能团队联合发起、共同研发的 IDE 标准化研发框架，早期在内部使用的名称是 KAITIAN（开天）。在准备开源时，考虑到 KAITIAN（开天）这个名称在国内外已经被大量公司进行了商标注册，为了避免后续由于名称引发一系列侵权问题，内部反复讨论后改成了 OpenSumi 这个新名称。

对于 IDE 研发，市⾯上早就已经有 code-server、Theia 等现成的开源⽅案，为什么当初还要选择⾃研实现一套新框架？一方面，随着阿里及蚂蚁集团内部对 IDE 产品的研发需求日益增长，各个团队在使用开源方案的实践过程中都或多或少遇到了一些问题，如定制能力有限、源码依赖深、维护困难、无法满足内部能力需求等。另一方面，阿⾥及蚂蚁集团内部有许多 IDE 产品，⼤部分 IDE 产品的前期建设⼤抵相同，但这部分前期建设工作的经验无法有效沉淀，存在大量重复劳动问题。为了解决这些问题，大家才决心集合多个团队的⼒量⾛上⾃研实现的道路。

OpenSumi 项目启动于 2019 年 5 月 8 日，在过去近三年时间里，从初见雏形的 1.0 版本，进阶到了大量应用的 2.0 版本。整体研发历程可以总结为以下三个阶段：

• 第一阶段：前期建设与核心业务落地。在立项之初，三个团队的研发同学进行了为期一年时间的闭关，目标是通过自主研发的框架承接内部三个较为重要的基础业务，包括蚂蚁的云端编码产品 Ant Codespaces、支付宝小程序开发者工具、淘系工程团队的云端编码产品 O2。在这个阶段，团队的重点工作是完善框架基础能力，以满足原有产品的能力及功能体验。截止闭关结束，共计迭代 67 个版本，实现了对 VSCode 1.37.1 标准 API 88.9% 覆盖，发布了 OpenSumi 的 1.0.0 版本。

• 第二阶段：业务落地及多场景验证。在完成 OpenSumi 的 1.0.0 建设工作后，团队开始在公司内部推广框架，进一步完善框架在更多场景和业务中的适用性，完成了纯前端能力、VSCode 1.44.0 标准 API 100% 覆盖、基础性能及体验优化等建设，在更多场景中完成了业务落地，如月服务开发者数量已达到 2W + 的小程序场景、月用户数达到 1.9 W + 的云端编码场景、IDE 研发中台、代码 CodeReview 平台、代码片段平台、场景化的本地研发客户端等。2021 年 3 月，OpenSumi 发布 2.0.0 版本，摒弃了一些不合理的设计，框架更加精简，性能及交互体验都有了大幅提升。

• 第三阶段：内外部开源。经历了两年的能力建设之后，考虑到国内并没有一款真正由国内企业或团队研发的 IDE 框架，另外在国内的开源环境下，想做好开源势必要提前做好相关准备，尽管原来代码就都是内部可见的，但团队还是在 21 年 的 4 月份启动了内部开源，加大了在内部代码分享平台上的宣传及建设，期间吸收了更多感兴趣的团队加入到了 OpenSumi 的代码建设工作中。2021 年 9 月份团队开始了开源建设工作，将工作流程及内容完全迁移到了外部，并完成了内部核心产品的依赖替换，后续将会持续在开源社区中完善好周边及基础能力建设。

在自研框架 OpenSumi 落地到内部 IDE 产品研发后，过去困扰大家的大部分问题都得到了比较有效的解决。比如对于定制能力有限的问题，OpenSumi 通过模块 + 插件的方式开放了全视图定制能力；对于源码依赖深的问题，OpenSumi 通过模块管理依赖，项目结构清晰，大部分模块均为 “可插拔” 模式，需要时引入，不需要时也可以不引入。

对于如何搭建一个 IDE 产品，团队也沉淀了丰富的快速开始案例及集成案例，开发者可以基于内部基建能力快速搭建自己的 IDE，不再像以前需要从一个简单的案例去盲人摸象式地探索完成后续需求研发工作。同时，为了满足内部能力需求，团队通过定期的月会机制收集各业务方需求，再通过进一步的需求抽象及逻辑剥离，将公共的能力沉淀在了框架之中，从而实现能力可复用。

OpenSumi 开源只是团队迈出的⼀小步，后续还有大量工作需要继续推进。目前 OpenSumi 每两到三周会进行一次迭代发布任务，由版本管理员统一维护合入相关功能及问题修复等内容。每次迭代过程中都会安排两名 “版本校验员” 进⾏版本检验，在测试通过后，才会升级一位 minor 版本后发布。团队将会持续性保证最新的两个 minor 版本的有效性，即 “如果发现了影响功能的问题，会向最新的两个 minor 版本同步修复，发布 patch 版本 ”。版本示意如图所示：

以 2022 年 1 月份的迭代计划为例，OpenSumi 版本发布的计划可见：Iteration Plan for v2.14.0（https://github.com/opensumi/core/issues/333）

当前 OpenSumi 2022 年的 Roadmap 也已经有了初步雏形，见 OpenSumi 2022 Roadmap （https://github.com/opensumi/core/wiki/2022-Roadmap），后续会根据社区反馈及讨论在 2-3 ⽉份正式确定。接下来团队会持续性地完成 VS Code API 的适配、编码 / 调试体验优化、性能优化等工作，同时积极收集社区中反馈的功能需求，以双周迭代的⽅式选择性吸收进框架计划中。

同时，OpenSumi 也有⼀些基础的长期目标，如下图所示：

前端 IDE 是阿里集团和蚂蚁集团从 2019 年开始就持续重点强调的一个核心技术方向。在 2019 年的 GMTC 全球大前端技术大会上，当时的前端委员会主席圆心在分享《前端路上的思考》中表示，期望通过 IDE 将前端工程领域中研发态与流程态进行整合联通，同时通过插件能力将阿里体系内外的研发模式、能力进行打通，形成生态能力发挥价值。而在 2020 年 12 月举办的 QCon 全球软件开发大会（深圳站）上，阿里巴巴前端技术专家张伟（上坡）在分享《基于 KAITIAN 的前端工程研发模式变革》中表示，KAITIAN 就是面向前述问题的答案。另外，蚂蚁云研发团队工程师王兴龙（蛋总）在 2022 SEE Conf 上也分享了《云原生架构下蚂蚁 Cloud IDE 的应用实践》，讲述了 Ant Codespaces 如何利用 OpenSumi 适配其双容器架构。

这次 OpenSumi 正式开源，意味着阿里集团和蚂蚁集团在前端 IDE 方向的发展进入了一个新阶段。

相比刚开始研发 OpenSumi 的时候，如今团队对于前端 IDE 的发展现状和未来趋势也有了一些新思考。

在 OpenSumi 项目组看来，IDE 的发展依旧离不开业务发展，IDE 的发展趋势一定程度上也可以从业务的发展趋势中窥见一斑。这两年发展比较迅速的 Serverless 未来在 IDE 领域上就有不少结合的可能性，比如提供给前端开发者搭建无后端的 IDE 应用，实现一些轻量的场景需求。同时，IDE 在一部分轻量编码场景下也有不少需求，未来的 IDE 研发可能不单单仅限于完整的一个 IDE 产品的研发，如嵌入网页中的轻量友好的代码编辑器、服务于低代码的可视化编辑器等，未来 IDE 的发展依旧会紧贴业务并为业务服务。

而从大环境看，目前依然没有一个 IDE 可以完全覆盖所有的业务领域，只在某个行业中会有一个比较流行的 IDE，因此 IDE 未来的发展趋势依然是着力于某个特定领域的精细化加工，未来 IDE 研发依旧会继续往更强的定制性、更友好轻量的集成体验上发展。可能未来的某天，会出现这样一个平台，能够根据开发者的需求，自动选择需要的模块及对应服务后为开发者提供一个云端的 IDE 工作空间，那时候可能会真正迎来 IDE “井喷” 的时代。