这样是试过,都是同样报错
请问EDITOR模式下，非插件脚本如何监听assets文件变更事件？
论坛有你而精彩
吊，，，，
一觉醒来看到这么长的评论还是很感动的。
回复第一点： 配置要面向业务配置，而不是面向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等等其他配置
有时候，自由，意味着更大的代价
认同，顶顶顶
喂大，无需多盐
问题是也并不是很自由
全部基于 vite，完整的接纳 vue 生态（而且不局限 vue，我们还提供了 react 的模板），vite有完善的构建机制，有非常详细的配置，还不够自由？
所以你想要什么？
我们不反对提出合理的建议，但是反对无脑拉踩。