这样是试过,都是同样报错
请问EDITOR模式下，非插件脚本如何监听assets文件变更事件？
我来深度评测下：
1. 配置要面向业务配置，而不是面向vit配置
开发者关心的是业务，建议把vit.config.js沉淀到底层
我的cc-plugin就抽象出来了cc-plugin.config.ts，注意为啥是ts，是为了方便智能提示，插件有哪些面板，菜单入口都有哪些，配置起来是符合直觉的
2. package.json字段冗余的问题
插件发布后，其实是不需要知道scripts、dependencies、devDependencies字段的
但是cocos-plugin cli是需要这些信息的，而contributions又是插件运行的必须字段，发现问题了没?
package.json的字段，来自不同的环境配置，为了每个环境都能正常运行，字段合并到了一起，糟糕的设计！
我的cc-plugin因为抽象出来cc-plugin. config.ts，根据这个配置，我可以保证新生成的pakeage.json的字段是符合目标环境的，并且没有冗余字段
3. 不能强制要求插件的工程必须放在extensions目录下
因为我要测试我的插件能不能在creator3.6， creator3.7， creator3.8是否正常？请问怎么搞？
我的cc-plugin通过cc-plugin.json灵活指定输出目录，修改下输出目录，只需要构建后，打开对应的creator工程即可，虽然还是有点麻烦，但已经好很多了。
并且我也考虑到了cc-plugin.json不应该纳入版本管理，所以cc-plugin会自动处理输出目录，没有cc-plugin.json文件，会提示你创建，更多细节需要你慢慢体会cc-plugin
4. 压缩混淆，tree shaking
这种基础的需求就不用提了，标配，cc-plugin已经实现了
5. 打包和构建要分开
目前构建后，想要上传到商店，还得再手动整理下
我要上传到商店，商店只能是zip，我还需要手动挑选出来package.json和dist，然后压缩一个zip
我的cc-plugin也把这个流程做好了，运行对应的脚本
就会在dist目录生成对应的zip，直接打开商店后台上传zip就行了，贴心的我还加了版本号，因为商店后台识别不了zip里面package.json的版本号，你必须得手动填写，zip名字里面就包含了版本号，细节拉满！
store对zip还有一个坑，2x和3x的zip结构不一样，区别在zip里面是否应该有一层目录，这也是我为啥要做pack的重要原因
6. 工程结构要更加符合直觉
事实上大部分插件90%的逻辑是渲染进程，也就是面板那个进程，要重点把这块的体验给拉满
cocos-plugin应该将部分配置文件想办法隐藏，因为开发者不需要关心这些文件，我个人也不想看到这个文件
对比我的cc-plugin工程结构
7. 需要开源案例支持
文档就不奢求了，最起码得有开源案例参考，开发者专注的撸业务逻辑，学习新东西当然离不开例子
我的cc-plugin提供的案例，其实还有很多插件我都是开源的，也后续都用cc-plugin翻写了，仅凭这一点，cc-plugin有上架的插件，就说明这个架构没问题，好多需求我最开始都是满足了自我需求的同时，一步步完善cc-plugin的，我遇到了这个需求，肯定有一天你也会遇到，cc-plugin就是这样沉底下来的。
| name | github | cocos store |
|---|---|---|
| icon-tools | https://github.com/son-king/icon-tool | Cocos Store |
| excel-killer | https://github.com/tidys/excel-killer | Cocos Store |
总结
评测了这么多，感觉像是在打广告，cocos-plugin的后续发展，相信cc-plugin是个不错的借鉴对象
最后再来宣传我的cc-plugin
-
使用 typescript + vue3.x 开发， 天然支持hmr(hot module replacement)热替换，开发效率更高。
-
插件开发更加工程化，支持代码 tree shaking ，更友好的运行环境判断，更友好的 nodejs native 模块支持。
-
封装了部分creator编辑器api，更友好的兼容性，更加统一的编写体验，更友好的代码提示。
-
配合cc-ui编写UI面板，多种常用组件可供选择，同时兼容性更好，在不同的creator版本上都能正常运行。
-
完美适配所有版本的creator，兼容性更好，同时支持发布web版本，配合
github pages、github action，方便给用户体验试用，进而引流。 -
完善的工作流：一键创建插件、打包插件、发布插件
-
发布的插件没有node_modules目录的麻烦，体积更小，用户安装更轻松简便。
-
发布的插件代码自动压缩混淆，增加用户二次开发难度，如有必要，后续会接入jsfuck/javascript-obfuscator等支持，进一步提高插件的安全性
cc-plugin更多的细节等你体验
readme文件
creator3.x中如果你的插件有readme.en.md / readme.zh.md 这两个文件，在扩展管理器里面就会展示出来
cc-plugin也把这个细节给完善了，因为反正要写文档，不如就把readme给写好，反正上传到store的时候，你还是要写文档的
支持web的黑科技
既然都用了web的cli了，如果插件能发布web版本，我肯定要发布的，用来引流试用再好不过了。
插件携带了一下静态文件如何处理
我想在发布后剔除特定逻辑怎么办
13赞
论坛有你而精彩
吊，，，，
一觉醒来看到这么长的评论还是很感动的。
回复第一点： 配置要面向业务配置，而不是面向vit配置
这和定位有关，你的 cc-plugin 定位是在 webpack+cocos 插件 的机制上层，封装出一套完整的解决方案。既然是完整的，所以你内部隐藏了 webpack 的细节，也隐藏了 cocos 插件的细节，对于用户直接遵守你的规则来写即可。 这只能说是你提供了语法糖。
这样做的优点是，用户只遵循你的配置就可以开发插件。但是他其实多学习了一套东西，他需要知道 webpack 和 cocoas插件 和 cc-plugin .
缺点是如果需要更高级的 webpack 配置是看你的文档还是去看webpack 的文档？
你能保证用户遇到一些配置问题可以在网上搜到解决方案吗？
我们的思路是完全公开透明，基于 vite ，只解决核心问题，也不引入新的概念，不引入新的配置，只是基于vite 的生态，加一个 vite 的插件而已。
本质上我们这个插件和你的 cc-plugin 是完全不同的定位。
我们不聚合默认配置是我们不确定每位开发者需要什么，有的人喜欢 sass ，有人喜欢 less，有的人要压缩，有的人不用，这一切都交给开发者自己去决定。（ps: 我们内部的项目可以约束，我确实有下沉一部分配置，这样上层的配置就看着很少，那是因为我们可以完全掌控自己需要什么配置）
关于 配置要用 .ts 文件这点，建议你了解一下 defineConfig 的作用，哪怕用 js 写配置，依然是有智能推导的。
其他关于 什么 混淆 tress shaking 也是 vite 开箱就支持的，我不太明白提这个意义是什么。
把 2 个定位不同的东西，强行比较就有强行推销的嫌疑，不过我们官方确实非常赞成开发者有自己的解决方案且愿意分享出来。但是不要拉踩就好。
用户只遵循你的配置就可以开发插件。但是他其实多学习了一套东西
是的，反正总是要多学一套，为啥不学一个兼容性更好的，反正无论是cc-plugin还是cocos-plugin，底层都是往编辑器的插件规则靠拢。
缺点是如果需要更高级的 webpack 配置是看你的文档还是去看webpack 的文档？
cocos-plugin准备怎么解决这个问题？不需要看vit的文档么？
你能保证用户遇到一些配置问题可以在网上搜到解决方案吗？
就目前的情况，是webpack的多还是vit的多？虽然我承认vit更胜一筹，是未来的发展趋势。
有的人喜欢 sass ，有人喜欢 less
可能有的cocoser连什么是sass，什么是less都不知道，怎么确定我喜欢哪个？更多的时候是有啥我用啥，只要方便好用
有的人要压缩，有的人不用
还有不用的？不知道为什么会这么想？
defineConfig 的作用，哪怕用 js 写配置，依然是有智能推导的。
import { defineConfig } from 'vite';没看出来有啥区别，不过我个人还是更喜欢ts，校验严格。
混淆 tress shaking 也是 vite 开箱就支持的
至少在生成的项目中我没看到，如果不查阅vit的命令行手册，我想把代码压缩下，怎么搞？我再去翻翻vit的文档？哦？原来如此啊，那再研究下vit？但是你想想？我就写个插件啊？这些不应该cli帮我做好么？写插件的人，至少我，我要的是一个解决方案，不是一个工具。
你在看看vscode的插件开发流程，从创建到发布，一个cli全包了，
只能说定位不同，思考问题的角度不同。
2赞
不过从你的回答来看，我也明白了部分开发者的需求了，自由度不那么重要，配置的灵活度也没那么重要，开箱即用。基于 vite 的配置，提出上层的简练后的配置。
我们本意是让用户完全掌控 vite ，从你的回答来看，似乎这点不太重要。
感谢建议，假设后期我们会更新 cli ，这个 @cocos-fe/vite-plugin-cocos-panel 依然会保留，因为它的功能非常明确单一。
开发者需要的是我们集合一些预设的插件，向上封装一个概念更少的东西。
说下自己的期望
-
插件 UI 界面
- 可以根据数据动态生成，让用户不需要自己编辑 UI，类似
@property - 可以自定义某个数据的 UI 展示，达到自动生成的 UI 和自定义的 UI 共同展示
- 可以根据数据动态生成，让用户不需要自己编辑 UI，类似
-
插件逻辑方面
- 支持脚本动态更新
- 配置尽可能简单且支持在脚本内动态配置，而不是放在 package.json 内
- 抛弃多进程概念，默认在一个进程内，将功能及接口集合在一个进程内
- 编辑器 UI 及资源的修改需要增强，例如修改节点树，资源管理器，生成/修改预制体
- 使用脚本接口代替 Message 方式，现在太不方便了，每次都要自己去看消息再写逻辑
1赞
一起维护，打造一个更好的插件系统。 
就是用户希望聚焦插件业务逻辑，并不关心是vite还是webpack等等其他配置
有时候，自由，意味着更大的代价
认同，顶顶顶
喂大，无需多盐
问题是也并不是很自由
