框架早期由阿里集团淘系工程团队及蚂蚁集团体验技术部、研发效能团队联合发起,共同研发的 IDE 标准化研发框架。它基于 TypeScript + React 进行编码,实现了包含资源管理器、编辑器、调试、Git 面板、搜索面板等核心功能模块,开发者只要基于我们的起步项目进行简单配置,便可以快速地搭建属于自己的本地或云端 IDE 产品,框架自身兼容 VS Code 插件生态,主流 VS Code 插件均可无缝在基于 OpenSumi 研发的产品中运行,同时,框架也为开发者提供多种低成本,高定制的视图定制能力,能满足 IDE 场景下绝大多数的视图定制场景。
对于 IDE 研发,现今市面上已有了 code-server、Theia 等开源方案,我们为什么选择自研实现?自 2019 年开始,我们便发现了阿里及蚂蚁集团内部已经有了许多 IDE 产品,大部分产品对于 IDE 产品的前期建设大抵相同,但是这部分前期建设工作占用的则是一个团队少则几个月,多则半年一年的时间,存在着大量的重复劳动问题,而在部分团队使用开源方案的过程中,大家也或多或少遇到了一些问题,如定制能力有限、源码依赖深、维护困难、无法满足内部能力需求等问题。最终,我们决心集合多个团队的力量走上自研实现的道路。
相信关注过 IDE 框架的同学对 Theia 一定不陌生,Theia 作为一款兼容 VS Code 插件的 IDE 框架,确实兼容了一部分 VS Code 插件能力,但对于后续 VS Code API 的兼容已经越来越少,基本依赖社区开发者的发现贡献。
OpenSumi 设计之初就是要兼容 VS Code 插件生态,故我们对于框架会有持续性的要求,开源之后,我们计划每三个月时间去完成一次 VS Code 插件 API 的适配工作,适配计划的制定,将会由相应的版本管理人员组织在讨论区进行,当前已适配至 VS Code v1.60.0 版本标准 API, 进度可见 适配计划 。
三 OpenSumi 与市面主流框架的区别
我们在设计初期便对 VS Code 、Theia 的源码进行了深入的学习,实现过程中,为了兼容 VS Code 插件生态,同时兼容主流编辑器的一些功能及体验,部分设计及实现上我们有部分源码也参考了两位老师的实现,对应代码区块已标注了版权头信息。
1 与 VS Code 的关系
VS Code 作为市场占用率较大的 IDE,其核心为一个 IDE 产品,本质上与我们的 框架 属性存在区别,整体上是一个 ToC 的产品,开发者进行定制的门槛及成本较高,可自定义的内容也比较有限,大部分是通过 插件 的形式进行有限拓展。
而我们的框架主要是服务用户为 ToB 用户,对那些需要通过 IDE 框架搭建自有的 CloudIDE / 本地 IDE 产品而又没有充足技术研发能力的中小企业是一个简单、便捷的开发选项之一。
2 与 Theia 的关系
Theia 作为后起之秀,借鉴 VS Code 的一些设计理念,经过近几年的发展逐步成熟,社区也相对繁荣,背靠 Eclipse 基金会,也是 IDE 开发者一个不错的开发选项,与我们的 OpenSumi 框架是存在竞争关系的。
Theia 本身提供了一种模块化构建 IDE 产品的能力,大部分视图上的定制绝大部分可通过 模块 的方式去进行拓展的(这点在我们的 OpenSumi 中也有借鉴相应思路),在 插件 能力上兼容了大部分的 VS Code 插件,提供了一份 VS Code 插件 API 的子集能力,部分插件 API (如 debug、language 等)并没有完全实现且也无后续持续性的跟进计划。
基于上面这些点上, OpenSumi 框架不仅支持了基础的 模块 方式拓展,在 插件 层面上,我们有持续性跟进 VS Code 标准 API 的规划 (当前已实现 VS Code 1.16.0 版本 API),同时,我们基于实现了一个前端沙箱,提供了一系列的 sumi API 用与通过 插件 的方式自由地拓展我们的视图能力,熟悉 React 的前端同学可以直接上手进行前端组件的编写,通过我们提供的丰富的 API 去实现相应的功能视图。
四 为什么要开源?
IDE 产品的研发,一直以来都是一件门槛较高,费时费力的事情,我们希望通过开源 OpenSumi 帮助对 IDE 有兴趣的开发者更好的了解并掌握 IDE 研发这项技术,让更多的开发者可以以一种低门槛的方式去研发自己的 IDE 产品,通过社区中开发者的使用,也可以帮助我们更好的改进我们的框架,获得更多的需求场景输入,同时,通过社区的影响力让框架获得更加长远的发展。
五 后续规划
1 版本发布
框架目前每两至三周会进行一次迭代发布任务,由版本管理员统一维护合入相关功能及问题修复等内容,每次迭代过程中我们都会安排两名 “版本校验员” 进行版本检验,在测试通过后,我们才会升级一位 minor 版本后发布,我们会持续性保证最新的两个 minor 版本的有效性,即 “如果发现了影响功能的问题,我们会向最新的两个 minor 版本同步修复,发布 patch 版本 ”。版本示意如图所示: 以最近 2022 年 1 月份的迭代计划为例,版本发布的计划可见:Iteration Plan for v2.14.0[3]