我也不想说什么了
随便搜一下都这么多问题
部分脚本还会被打包到bundle文件夹外的src/chunks/bundle.js
没法跨项目使用
整的比2.x还难用的多
2023年了来回一下现在的状况
现在最大的问题还是搞不清到底怎样的代码会被打包到src/chunks/bundle.js而不是原本的bundle中
我项目也没有代码是主包跟子包都使用到的情况
顶多有两个子包的代码有相互引用到
而这篇中的询问使用跨项目的远程包的方式
官方最后的回复是直接在settings.json的设置新增另一个项目的bundle.js
虽然可以解决跨项目的问题
但也造成了无法透过加载相同项目的不同版本的bundle
无法做到热更新的效果
这篇的问题跟我遇上的很相似，可惜也没人理
你可以自己修改引擎中加载bundle那一块的代码，跳过那个js的加载，不影响运行。
cocos用meta和uuid，bundle这种方式来做加载，真的很蛋疼，多人流程和复杂度太高，不方便做h5游戏，反人类，已经粉转路人，等laya3.0下周发布了 ，laya简单简洁多了 
抱歉，据我所知， laya 3.0 也是用的 uuid
1赞
3.x bundle打包时各种bug，我之前就提了几次，不知道现在有没有修复了。 
抱歉，现在脚本跨项目确实还存在很多问题，我们会作为一个专项去解决
目前这块的任务还在排期中
2赞
太好了，很开心看到官方有解决这个问题的想法
我想说下我自己这块的情况
1.想要直接把编辑器作为玩家MOD编辑器，跨项目。玩家能够直接输出一个bundle，然后打成ZIP什么都行，反正最后变成bundle文件夹后，我游戏客户端再去加载。
2.本身我自己构思，mod和游戏主体的逻辑和数据这块，只要有一套稳健的消息系统，应该就没有什么问题。
3.但是实现到后面发现，如果代码是继承 Component的时候，不能重名。但是玩家在开发MOD的时候，也不知道其他MOD的组件，用的什么名字啊。。。，而且Component那么多。。
4.这就导致了使用受限了。。
希望各位能解决一下，或者提供一下思路。。。
脚本加项目缩写前缀，如：MOD_Script1.ts 虽然这很蛋疼，但貌似可行。
但如果不同项目，使用了相同的第三方库，该怎么办呢
不能这样啊，就像我第3点说的，玩家在开发MOD的时候，是不知道其他玩家开发的MOD，是什么命名的。就会导致加载多个MOD时候，很容易出现这个问题。。。
提供用户注册账号的功能，可以设置自己的前缀，并且唯一，所有脚本加前缀，脚本不能重名设定没有什么问题，如果放开这个限制，一个项目里面大家为了方便，不想起名的时候，都叫一个通用的名字，最终项目里面有大量重名，找代码和排除问题变得很复杂
这个 brasil7.ts 生成的名称能自定义么 因为不同bundle 同名文件打包后 brasilX X会随机变化
最终有结论吗？这个项目等了几年没转过来
可不可以代码放在主项目， 然后资源什么的放在bundle包， 这样打出包来呢， 最近见到一个大厅加子游戏的框架是这么弄的。
你好，这个问题，3.8 新增了独立的 bundle 构建功能，可以打包处不会依赖 src 下脚本的资源包。可参考文档查阅使用 https://docs.cocos.com/creator/manual/zh/asset/bundle.html#构建-bundle
Q ：Asset Bundle 支持跨项目复用吗 A ：目前版本支持，但我们 不建议跨项目复用 ，随着引擎的更新迭代，这可能会产生各类兼容性问题。在目前跨项目复用需要满足以下条件：
- 引擎版本相同。
- Asset Bundle 中引用到的所有脚本都要放在 Asset bundle 下。
- Asset Bundle 没有其他外部依赖 bundle，如果有的话，必须加载。
- Asset Bundle 之间尽可能不复用脚本
这些限制导致基本没法使用。 跨项目使用必须要有。跨项目的情况肯定有库的复用
太灵活的话会导致：
- 脚本依赖和资源依赖很可能不一样
- 脚本依赖的顺序和 bundle 的加载顺序（优先级）很可能不一样
所以脚本要如何和资源 bundle 一起，又能独立共享呢？你的建议是什么呢？
大佬，目前需求是：bundle能够完全独立于项目，支持热插拔式组装。这样非常利于bundle的复用。就如unreal的子系统设计到插件再到gamefeature，引擎提供能够支持复用的机制，至于脚本和资源的引用和加载关系提供依赖配置交给开发者自己设计。
脚本要如何和资源 bundle 一起，又能独立共享
1、是否可以设计为打包时配置是否将bundle之外的lib打包，或者通过提供配置让开发者自己决定需要和不需要打包进bundle的公用lib。
2、在bundle加载时设计一种机制，根据目前是否已加载的js环境决定是否需要加载依赖的lib。
作为开发者来说，自己改造引擎支持的话我会从引擎模块设计的导入映射功能入手，虽然目前为止它也还只是试验性功能。 开发者可以将公用lib设计为一个模块映射。然后在项目和bundle中通过映射的方式引用。在打包bundle时修改打包对应的脚本，处理好映射和上面提到的依赖配置和加载关系。应该也是可以支持的。
纯粹吓bb，不喜勿喷。最终目标还是需求导向：希望bundle的设计能够尽量做到跨项目复用。
1赞
如果你的bundle是完全独立没有外部依赖那就可以跨项目复用
目前关于这一块，我自己手头公司的项目是如下方案：
1.资源放在一个COCOS项目，做远程Bundle，这里没有代码，就预制体，动画，图片音乐这些。
2.编辑器放一个COCOS项目，这个是给策划的，我自己拼了一个资源管理器，读取上面的资源。然后导出一个数据。放在静态资源服务器。
3.游戏本体一个COCOS项目，只有一些基础的UI等关键资源。游戏本体的代码都放这里了，一开始进入游戏加载资源Bundle，然后需要用到编辑出来的东西就直接去服务器读取。
缺点：
1.没有办法很好的利用Cocos自己的编辑器，这一层基本是开发在搞，策划美术接触的都是我自己写的“游戏编辑器”。
2.流程管理需要有序，脑子稍微乱一下就会做错。
3.代码更新都在用游戏本体了，不能做到像传统Mod那样的，脚本跟着走，这也是为了防止冲突考虑。
1赞