目前的Cocos版本是不支持同一个文件里有多个Component组件的。但需求环境还是有的。目前我们内部需要把自己做的框架打成一个js文件和一个.d.ts当作一个完整模块给外部技术使用。由于框架里面有大量的Component组件，导致无法正常使用，建议官方支持一下。
这种级别的改造只能付费定制了。Unity 在跨团队协作时也是鼓励完全开源的。
设计如此，暂无计划支持这种情况。
框架代码和组件是两码事，所有框架接口可以都写在一个文件里，不需要挂载
可以知道一下，这个设计是什么原因吗，为了实现或者是避免什么问题。
想象一下将多个组件的脚本拖拽到节点上，会发生什么事情
可以第一个，也可以最后一个，甚至可以随便一个。
如果想要精确脚本里面的其它Component，可以搜索名字。
没什么原因，纯粹就是这个需求太小众，有其它更重要的事情要做。
unity不仅一个cs只能有一个组件，连名字都必须和文件名一样呢
这种需求的话，可以退而求其次
js里面有各种Component组件，但是不使用@ccclass注册
导入使用需要使用的话，继承自js里的组件，并使用@ccclass注册
即可
稍微麻烦了一点
问题是，这个不是一个需要开发的功能，而是一个被禁止的功能，只需要开放回来就可以了。
意思是用户体验和需求就不是重要的了。
请教一下，有没有示例，我看看我这边能不能改。
感觉你还在强制用典型的前端思想套用到游戏引擎
我觉得你认为游戏引擎的一个sdk/包/库/框架，最终导出为js/ts，就可以了
但是其实不是的，游戏引擎的一个sdk/包/库/框架，他的组成可以是
- 脚本
- 材质
- 贴图
- 特效
- 模型
- …
只是一般情况下，脚本可以涵盖大部分想要暴露给外部使用的，所以你认为这样子就可以了
实际上，游戏引擎的一个sdk/包/库/框架，Cocos这边一般对这些东西的组成叫 扩展资源包
给到开发者那边使用，他大概是这样子的
不单纯是一个 js 叫可以了的哦
当然如果不涉及到组件，贴图，模型等这些，只是纯js就可以搞掂的，其实传统js那种也可以的，比如 crypto-es ，他就是一个纯js/ts加密的库，所以可以这样子做
1赞
那可以再考虑一些其他边缘问题：
比如自动挂载了第一个组件，之后研发人员把第一个组件删除了，会自动切到第二个组件吗，还是直接 missing script ？
研发又回滚了这个删除操作，能再次把第二个组件切回第一个组件吗，第一个组件的配置数据能自动找回吗？
这些都是设计上需要考虑的问题，当然问题肯定不止这几个
需要有一个完整的设计方案，而不仅仅只是开关一个功能这么简单
在使用框架包中的组件时新建脚本继承组件在挂载不行吗
这种挺好的
所以设计上挂脚本时显示脚本+组件就能满足了。每当挂脚本时如果有一个组件自动挂，有多个的时候可下拉选，选后锁定面板就能实现。只不过没必要这么麻烦
简单问题复杂化，馊主意，嗒咩
感觉这个像是我想要的功能，我试试看。
再请教一下，使用了 **扩展资源包**功能，如果里面的资源没有被项目引用，在发布的时候，没有被引用的资源或者是脚本会被打包吗。
还有就是 外部模块 这个功能，如果脚本没有被引用，发布的时候会被打包吗。
这个扩展资源包是如何开发、构建、发布的，建议你去看一下官方文档
https://docs.cocos.com/creator/3.8/manual/zh/editor/extension/readme.html
像你有组件暴露给外部开发者使用的话，这应该是比较官方的一种发布方式