666，终于有官方支持了。
刚好在用element-plus + vite + electron写一个工具，配合上AI要一些简单插件就是问AI一句话的事 
各位大佬们可以踊跃提意见，后续我们整合方案后会融入 creator 中，作为模板创建的基础功能，降低大家开发插件的困难。
想要一个用 cocos creator 的 prefab + scene 这些概念做的一个 cocos creator 插件的教程
-
配置过于繁杂
-
脚本逻辑不能热插拔，例如主进程脚本必须重启编辑器
-
场景脚本、主进程、渲染进程，增加了开发复杂度
光是理解这三个都阻拦了一大批人开发插件，或者导致未理解时开发的程序 bug，例如在主进程或者渲染进程 import cc
对于插件开发简化我之前做过尝试，还算比较成功，可以参考：秀下工作成果：QuickPlugin，一个文件即可创建插件，颠覆插件开发
但是对于理解进程这个对于开发者还是硬伤，必须清楚才不会写出 bug
这个我做过，就是用 iframe 嵌套就行了
我也是刚刚接触electron和vue，有ai的帮忙进度提升了非常多，差不多80%的代码都是AI写的 
写了这么长的文章来介绍这么拙劣的插件开发方式，我只能说，真有你们的。但凡看看unity编写插件的方式就能明白你们如此晦涩难懂的玩意究竟是不是给用户用的。复杂点的，unity可以写出自己的编辑器，简单点的比如给Hierarchy的特殊节点加个边框。
[InitializeOnLoad]
public class HighlightHiddenObjects
{
static HighlightHiddenObjects()
{
EditorApplication.hierarchyWindowItemOnGUI += OnHierarchyGUI;
}
private static void OnHierarchyGUI(int instanceID, Rect selectionRect)
{
GameObject gameObject = EditorUtility.InstanceIDToObject(instanceID) as GameObject;
if (gameObject != null)
{
if (SceneVisibilityManager.instance.IsHidden(gameObject))
{
Rect outlineRect = new(selectionRect.x - 2, selectionRect.y, selectionRect.width + 3, selectionRect.height);
Handles.BeginGUI();
Handles.color = Color.white;
Handles.DrawWireCube(outlineRect.center, outlineRect.size);
Handles.EndGUI();
}
}
}
}
你们这玩意的架构几乎难以让插件简单开发。成本之大，难以想象。不说unity，距离laya的编辑器插件实现都不如啊。看看这长篇大论，满篇都是在介绍web。满篇都是在hack。但凡是个正常游戏开发(是游戏开发，而非cocos开发，更不是web开发)看了都直饶头。
比如插件需要扩展修改原有inspector逻辑，cocos做不到。为什么做不到呢？因为用户写的inspector插件和cocos自带的inspector插件压根不在一个进程。用户是做不到，但是cocos本身做得到吗，做得到！只需要有清晰的架构就完全可做。为什么不做呢！别问，问就是不想做。可以自己实现一个笔刷在cocos场景里面绘制吗？不可以，通通不可以。架构就是如此不UGC。cocos希望所有的插件开发者熟悉cocos editor就像cocos editor开发者一样熟悉editor本身。当然引擎已经把大部分inspector放到了cocos engine / editor下开源出来了。但是由于上手成本实在太高，折腾收益完全不值得。
我只想说，距离一个合格的，更多人愿意开发插件的架构还是太远。为什么js可以在世界上拥有最多程序，npmjs 是世界上最大的库管理。别问，问就是js足够简单。所以，别问，问就是cocos editor plug插件开发实在是足够复杂。且 自由度 很低很低。
插件结构设计已经定下来了，要改也是 creator 4.0。 3.x 目前只能用这套机制。这个文档主要是让大家更方便开发 panel， 而编辑器的panel 就是个纯粹的 web 的东西，不谈 web 谈什么呢？
而且，请问什么地方是属于hack， 如果没有使用 第三方 UI 库， 其他一切流程，都是非常常规的 web 开发方式。
针对 第三方 的 UI 库需要 hack ，也说明了原因，那是我们用了web-component 导致。
会的人不看 看的人不懂 和新手一点关系都没有
官方正在向美好的方向探寻，支持一波 
感谢引擎组对插件系统的关注，大部分同意前面 @972579559 @544430497 @1226085293 大佬们说的。
这堆屎山还是抛弃吧，别浪费时间了，赶紧 4.0 重构插件系统吧。
编辑器不开源，插件系统还整成这样，不是我们想什么东西都要官方做，但是只有运行时开源，我们即使想无私贡献，即使愿意吃屎，也做不到啊。
插件还是换一个思路，不一定要用 web 那一套。开发者肯定是会 Cocos 这一套。你让开发者去弄 css，html，UI 学 2 套？
插件开发的基本流程应该是：
1、创建插件；
2、调用插件 API；
3、专注业务逻辑
4、上架；
官方让开发者去注意各种乱七八糟的配置。谁看得下去？不要用开发的思维去做产品啊。能实现和简单是 2 个概念。
说几个痛点:
1.打包构建的包没有工作流,直接出node_mudule文件夹,用户下载完提交到git全给过滤了,本来几M的包一下子变成几百M
2.代码加密混淆,上传商店前还要费力去做加密,要不然不敢发上去卖
3.ui调试很痛苦,改行代码每次都要重启编辑器,和场景交互的脚本,普通编辑(这里的vue界面可能只要重新构建脚本打开一下就可以,但是不确定哪些可以哪些不可以的情况下,大部分都是重启)因为不确定到底会不会生效的情况下,为了防止不生效,大概率会选择最保险的做法,重启,漫长的等待
4.消息调用没有封装,特别麻烦,希望可以直接通过代码的方式进行调用,还有很多的隐藏api,要不停的测试,测试过程又特别痛苦,而不是每个都要打开消息面板去查找,附上我的封装editor_warp.rar (8.1 KB)
5.消息支持有些地方可以,有些不行,比如场景内脚本,编辑器右键,资源操作,发消息的预期结果不确定
6.ui界面开发能够快速接入vue组件,(我理解应该是这次解决的问题)
7.目前功能和编辑器本身的契合度太低,很难扩展编辑器本身功能,比如要添加一些节点边框,相机预览常驻,下拉定制,批量操作等功能都特别费劲,只能做一些边角料的扩展,或者脱离编辑器相关功能
确实如此。但是目前架构就这样了，也只能屎山上做优化了，我每次开发插件都想跳楼，一个menu都要先配置，都不能动态增加。
如果想变成unity那样，估计要放弃web开发架构，direct ui才是方向。实在不行真的可以参考laya 3.0
希望简化一下，拜托了 
能不能在编辑器里面直接拼插件界面 
随便挖一下以前的一个帖子，以前提过下
到目前为止，我也还没有想到什么好办法，解决这个问题