解释一下为什么 3.7 要弃用全局插件

3.7 升级了扩展管理器,采用了全新的 UI 并且支持一键安装和更新扩展插件,还支持记录和安装项目所依赖的扩展,让项目的分发更加方便。


为了实现更好的版本管理,提高扩展稳定性,新版扩展管理器也调整了一些管理机制:

1. 3.7 开始编辑器将不再读取全局目录下的扩展,老项目升级到 3.7 时将会自动复制全局插件到项目中。此功能通过配套的 Dashboard 1.2.4 实现,请先确保本地 Dashboard 已自动更新至 1.2.4 版本。
2. 从扩展管理器中安装的扩展将记录依赖关系,通过 Dashbord 1.2.4 以上版本打开项目时会自动检查并安装依赖的扩展。此功能目前还不支持 Store 中的插件,我们将在之后的版本中继续完善。
3. 开发中的插件可以通过点开扩展管理器上方的导入按钮小箭头,选择开发者导入(Developer Import),此功能将为外部插件创建软链接到项目中,避免了插件同步问题。
4. Store 中的插件如需共用,在 3.7.0 仍与之前一致,需要在各台电脑上分别手动安装,或者将插件内容上传到 Git 版本库。

其中最重要的就是第一点,不再支持全局插件。这个决策确实很难让人理解,本帖尝试进行一次集中说明。这不是为了争辩或者打压社区,而是希望能够让信息流动更加高效、更加公开透明。如果有新的反馈建议仍然欢迎在本帖继续交流,我们仍然愿意做出改变。

起因

此决策始于 21 年底,新版扩展管理器筹备阶段。由于新版扩展管理器牵涉到原有插件系统、Dashboard、Store 等众多模块,要解决各种兼容性、体验性问题,因此遇到了很多困难。经过大量调研和讨论,我们决定废弃全局插件功能。

与全局插件相关的问题

  1. 多个插件位置导致的逻辑混乱

1.1 这样就会导致插件的配置可能存在多个地方,编辑器、全局、项目(本地配置)、项目(git 同步配置),这些配置会互相影响,可能 A 插件会有部分配置从 B 加载,部分配置从 C 加载,开发者和使用者都很可能会搞晕。
1.2 除了配置,插件本身也会相互覆盖,编辑器插件有 3 个层级,内置插件(实际上内置插件还分成两种来源)、全局插件、项目插件。一个插件在多个地方存在不同版本的话,使用者可能就无法意识到自己使用了错误的版本。

  1. 多个插件版本导致的配置混乱

2.1 若全局共存有相同插件的 N 个版本,这些版本之间的全局配置就会产生冲突。

例如 Creator 2.4.11 禁用编辑器自动刷新资源后,导致 2.4.10 的项目也禁用了…… 因为这个配置其实 2.4.10 本来就有,但是 2.4.11 才开放了这个设置界面。用户本意是只让 2.4.11 禁用的,没想到配置文件串了。这类型的错误还有很多衍生版本,这里不再展开。

  1. 选择困难

3.1 所有涉及到插件的操作,都要让用户指定是安装到全局或者项目。当全局并存多个版本时,还需要让用户选择要使用哪个版本的插件。这不仅仅是在插件安装环节出现,在项目版本升级时,也需要让用户重新选择全局插件要使用哪个插件版本,否则编辑器可能不兼容。

想象一下,当用户安装的插件多了以后,每次建项目,都得从一大摞插件里面挑出要加载的全局插件…… 这个挑选过程要把体验做得好又要费一番功夫,体验不好肯定会被吐槽建个项目都得纠结哪些插件要加载。如果某个插件本地安装的版本与特定编辑器不兼容,用户还得挑选完插件后记得切换版本才行……

  1. 项目分发困难

4.1 很多插件是开发者自研的,并没有注册到扩展管理器中。这时分发项目给其它人的时候很容易漏发全局插件,导致对方无法运行。我们在跟开发者或者内部团队要 demo 的时候,经常就因为少了插件导致编译失败,增加了问题排查和沟通的成本。

4.2 即便目标设备上有指定插件,由于版本很可能不匹配,也可能会出现奇怪的问题。增加了排查成本。

4.1 和 4.2 可以通过在扩展管理器锁死插件版本来解决,不过这样又会导致问题 3.1,只要已安装的插件版本不匹配,开发者就又需要强制切换版本,切换后重新锁死版本,再分发给别人又会引起别人的版本不匹配。

  1. 插件版本碎片化严重

扩展管理器支持热更后,插件的升级会比现在方便很多,如果用户逐版本升级,就会在全局留下很多老版本,这些老版本无法被清理。因为扩展管理器在升级时无法判断老版本是否还会被其他项目暗中使用,让用户自己清理的话同样会出现误删除的风险。

想象一下,当开发者看到全局目录下一溜的老版本,是不是又会吐槽 Creator 竟然不会自动清理?用户自己又怎么知道哪些版本能删?

总结

以上只是我尝试总结的一部分原因。由于相关的调研比较杂乱(最近几年我们至少建立了 10 个扩展相关的 GitHub Issue 和 Discussion 来讨论和调研,文字量不亚于 10 篇这样的帖子),我这里的总结可能还并不全面。

Creator 的扩展机制遇到了很多挑战,各种 Store 的插件、项目、Dashboard 的配合、多项目多编辑器多插件这三者如何组织和共存、已安装的插件何配置如何处理…… 还有我们之后规划的一些新的更新机制,都在干扰我们的实现。全局插件只是其中混乱的一个源头。

上面这些问题每一点单独拎出来当然都是可以通过产品或者技术层面去解决的,只不过我们觉得选择比努力更重要。秉持着 KISS 原则,我们宁愿把扩展机制先做得笨一些,也要让他能够尽可能的简单和可靠,特别是对新手而言。稳定和可靠对 Creator 来说是最重要的,其次才是性能和易用。因此只要全局插件会在 5% 的使用场景中带来潜在的可用性问题,特别是只要全局插件容易对新手造成困扰,我们就有必要从机制上彻底解决。

我们也会在这个机制上继续优化,优化一些体验问题,例如新版的扩展管理器支持开发者导入一个本地插件。不排除后续我们也会用类似的机制来解决一些便捷性问题,我们也欢迎诸君在本帖提出改进建议。

Q&A

Q:可以设置插件更新不再覆盖,以目录区分, PackageName/v1.1.1/ ,由用户在项目中选择开启哪个版本,如果旧版本确实不需要,交由用户是否卸载
Q:应该将插件安装到全局,然后在项目配置文件中配置是否开启。而且dashboard来管理插件的话,全局更方便管理
A:项目的创建是很高频的操作,偶尔一两次让用户在项目配置或者 Dashboard 里精挑细选其实还行,长久以往其实还挺繁琐的。会出现 3.1 的问题。持续优化这个选择过程的话,最终就会变成创建项目时默认什么插件都不安装,有需要的话再选择安装。那其实已经跟现有的扩展机制非常像了,只不过现在是通过“导入”或者“自动下载安装”。唯一的区别可能是“找插件”可能没那么方便,这个我们后面会持续优化,比如推出收藏夹之类的功能。实际上只要涉及到“让用户选择”,那是否安装在全局已经不重要了。从体验的角度来看浪费的那点硬盘空间不值一提,实在不行还可以用软链接绕过。

Q:如果用户的插件过多,是否采用项目独有,应该交由用户来选择
A:无法解决上述 5 个问题,还多出了新的 实现成本、理解成本、排查问题的成本…… 我们不希望把 Creator 做得过于复杂,到最后我们自己都 hold 不住,稍微改点东西都可能因为考虑不周引发新的 bug。

Q:我想不出全局插件,还有其它所谓的项目独有就没问题,全局就无法保证正确运行的问题
A:上面这些问题每一点单独拎出来当然都是可以通过产品或者技术层面去解决的,只不过我们觉得选择比努力更重要。一个根源上容易出错的机制,打再多补丁也是徒劳。

Q:我们N个项目都要拷贝1份要疯了。
A:3.7 正式发布时会配套升级 Dashboard 到 1.2.4,1.2.4 加入了老项目升级到 3.7 时自动复制全局插件到项目中的功能。抱歉公测期间 Dashboard 暂时还没来得及升级,所以导致开发者要手动拷贝。

Q:自动拷贝到本地没用啊。我们几十个项目,不能指望着他们后续会主动同步这个。用全局插件开发时我们做自动更新。
A:使用“开发者导入”,选择插件在本机的共享目录。此功能会帮助开发者在项目里创建一个软连接,这样插件就能从本机任意目录自动同步了。
image

Q:你说的这些困扰基本无关痛痒,论坛里基本也没有什么反馈;反馈的一些核心问题没怎么动,改这些帧没必要,而且改的还不好
A:Creator 今天的用户量十分庞大,产品需要能尽可能 100% 解决问题。哪怕只会造成 1% 的用户或者 1% 新手困扰,都必须从产品或者技术层面解决。我们是没有人力去逐个进行技术支持或者解释要如何用对产品的。

Q:像我这有十多个插件的,每个项目都导入一边,就会有几十乘以十几份。这考虑的太少了啊。这处理的太过分了!!!!
A:我们后续会优化插件批量导入功能。开发者本地的插件现在也已经支持单独加载,不需要放到项目内。

Q:我在商店出售的商品,如果用到本人自己的插件了的,价格决定不会低。如果用到了他人的插件,我不会在商店出售。
A:要分享项目时剔除私有插件,目前最推荐的办法是使用 git archive -o xxx.zip <分支名> 命令,此命令会把当前项目打包为 zip,并且剔除掉 .gitignore 文件中的资源,这样就不会包含 library、temp、local 等本地目录,只需要在 .gitignore 里面排除不希望共享的插件路径即可。后续我们会考虑在 Dashboard、扩展管理器中集成类似的管理功能。

Q:上传 git 时,ignore 掉另外人或另一台设备拉取就没有各个使用的插件,不 ignore 掉,仓库会多一堆,且大家都能处理这个插件,一个人没弄好,插件这块难维护了。
A:项目组要用同一个插件时,如果是私有插件就别 ignore,这样也能避免版本不匹配带来的问题;如果是公开插件,3.7.0 加入了注册机制,将来会扩大到 Store 的所有插件,到时候别人就会自动安装,不需要放到 git。

4赞

我觉得应该将插件安装到全局,然后在项目配置文件中配置是否开启。不然每个项目单独的话,个人感觉非常麻烦。而且dashboard来管理插件的话,全局更方便管理

如果已经要用项目配置来配置是否开启了,那不就是每个项目单独了?具体回复在 Q1 里面了。

感觉现在 Cocos 是不是不够开放,感觉开源只是源码开源,并不是一个作为开源项目去运营。

无法了解引擎的进展,之前还有 roadmap,之后不进行更新断断续续,后来有 github projects,但里面很多 item 都是锁住不让看,可能是想给我们一个惊喜吧,现在整个 projects 也看不到了,每次只有发布社区版的时候才知道,然后发出感叹原来这么久了引擎组是在做这些

大部分正在做的,或者是准备做的功能也没有在论坛集思广益,比如新扩展管理器,我在 GitHub Issue 和 Discussion 没找到相关的讨论,平时看引擎的 commit 的时候也是,引用的 issues 或者 task 很多都是内部限制访问的,外部人员无法查看到具体内容。

忘记引擎组谁说的先服务好 cocos 自己的用户,但对于论坛热门的,呼声高的功能请求感觉就是慢得很,是否可以在排功能优先级的时候在论坛进行投票。

如果先沟通,感觉也不至于总是在出现争议的时候进行解释。

1赞

很抱歉现在确实没办法像传统开源社区那样运营,我们内部要服务的业务线挺多的,也有不少商业合作项目,这些都不能随意披露。引擎的仓库已经尽最大努力公开,开发者反馈的 issue 大部分都会建在这里 Issues · cocos/cocos-engine · GitHub ,包含的 PR、Discussion 也都是公开的。

Roadmap 这东西目前缺少人力去好好维护,一方面是无专门的 PM 梳理规划,另一方面是规划现在由很多小组自主完成,每个小组进度和披露的信息存在出入。很多时候我们也没人力把定下来的设计完整的写在 Roadmap 中,如果仅仅写一个“启用新版扩展管理器”,相信大家也看不懂。

开发速度问题,现在确实比较慢。22 年为例,发布了 4 个大版本(算上 3.7),但实际上 3.4 是 21 年完成的,3.5 是临时插入的中间过渡版本。也就是说 22 年就完成了 3.6 和 3.7 两个比较大的版本。这种情况下一个任务从讨论、立项、设计、开发、联调,最终测试通过,中间被一些更高优先级任务插入后,如果错过一个大版本,延后到下一个大版本,此时过去了一年是很难避免的。

现在的开发节奏已经是稳定优先了,我们很难做到一些呼声很高的东西不经上述流程就轻易进入下一个版本(即便是下一个版本也差不多要半年,大版本就是要这么久),偷工减料很容易引入新的历史包袱,将来必须持久保障兼容性。也更不可能在小版本里乱加东西,破坏稳定性。

如何让开发者感觉到更高的响应速度?

  1. 最直接的,获取企业技术支持,我们有专门的团队对引擎和编辑器进行定制。小范围的需求能够很快满足,不需要经过全平台、各种使用场景的论证和测试。
  2. 通过各类插件、生态解决,这需要我们持续提高开放程度,繁荣 Store 生态。
  3. 新功能更好的落地到老版本,让开发者可以不需要等到“真正稳定版”就能用上新功能,扩展管理器就是在朝这个目标努力。

是否可以在排功能优先级的时候在论坛进行投票?

如果我们拿不定主意的话确实是会的,我经常发一些奇怪的调研帖子。不过现实情况是我们的任务已经多到做不完了…… 每个版本都感觉有无数超级重要的任务不能延期。这种情况下往往只能根据我们各个功能小组的“剩余人力情况”来分配优先级。

带开发者导入功能的dashboard预计什么时候发布?

1.2.4 今天就会上线

明白,确实人力不足

支持!祝更好!

1赞

支持!祝更好!

1赞

请问,3.7.1和3.7.2目前计划仅是bug修复,有新的功能吗?这个近期的计划有透露吗?

目前没计划新功能

这块倒是能想明白。而且我一直觉得插件跟着项目是对的,要保持引擎编辑器那边的纯净性。如果需要深度定制,也不应该简单的用插件去实现。那样如果这种插件安装的多了,编辑器就会像一个改装车一样,稳不稳定全看师傅了。更不好追BUG了,我就觉得插件的教程很少。。尤其是插件UI那块。我没有做过H5,以前都是做游戏客户端的,VUE那些是真不懂。上手不能说很难,但是很多很繁杂。又是CSS又是HTML。不知道官方能不能提供一些简单的UI框架,就直接一个JS写完得了。。。

3.8 会提供一个框架用来支持一些简单的 UI 开发

嗯嗯,挺好的,加油

我觉得你的Q&A完全没说到我说的点子上,你创建项目是高频,那你是不是还得自己管理插件?你现在创建新项目,是否会拷贝插件?拷贝哪些?如果有拷贝,那不就是我说的开启吗,你在配置文件里做个标记就行了,如果不拷贝,那就表示插件默认关闭嘛。至于你在其他Q&A说的软路由,如果原文件被删除了呢?如果用户希望某个插件清理干净呢?

你的点子不就是装到全局 + 项目配置吗?那样会遇到一楼说到的问题 1、2、3、4、5。好像原有的问题都还是有……
要弃用全局,本来就不是为了解决“加载过多插件”这样的问题。

+1 很讨厌web的那一套东西硬到游戏上来,,,我只想简简单单的通过js或ts处理游戏的一切,,

1赞

弃用全局插件我觉得完全可以,只是之前习惯了全局插件的人一开始 会有点不适。unity没有全局插件这个功能,大家不也用的好好的,主要是插件安装和升级要方便。

1赞