兼容VS Code插件国内⾸个强定制IDE研发框架 OpenSumi

采访高朋 | OpenSumi 项目组

经由近三年的研发和内部运用处景打磨，由阿里集团和蚂蚁集团共同打造的 IDE 研发框架 OpenSumi 于近日正式对外开源，采取目前利用较广泛的 MIT 宽松容许协议。

项⽬地址：https://github.com/opensumi/core

官⽹地址：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 不会走上同样的道路呢？

对此 OpenSumi 项目组回应表示，开源项目能持续下去最主要的是担保项目的代价，这才是持续吸引开拓者来共建和利用的核心缘故原由；其次是开放管理 Open Governance，让外部贡献者也能在公开透明的管理构造里参与项目的关键决策，让 OpenSumi 成为不是阿里、蚂蚁两家公司在做的开源项目。

“开源初期我们便把所有核心代码一次性开放到了开源仓库中。
得益于 OpenSumi 极强的拓展性，我们内外部的许多核心产品在今年 1 月份已经完成了从内部依赖切换到开源依赖的事情，不再区分内部版本和外部版本。
我们希望通过这种办法，一定程度上帮助 OpenSumi 在开源社区中持续发展下去，逐步从内部的一个开源框架发展成为开源社区中能让大家广泛接管的 IDE 研发框架。
”

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 该如何选择？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，不再像以前须要从一个大略的案例去盲人摸象式地探索完成后续需求研发事情。
同时，为了知足内部能力需求，团队通过定期的月会机制网络各业务方需求，再通过进一步的需求抽象及逻辑剥离，将公共的能力沉淀在了框架之中，从而实现能力可复用。

前端 IDE 发展的下一步

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

以 2022 年 1 ⽉份的迭代操持为例，OpenSumi 版本发布的操持可⻅：Iteration Plan for v2.14.0

当前 OpenSumi 2022 年的 Roadmap 也已经有了初步雏形，⻅ OpenSumi 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 “井喷” 的时期。