嵌套进cocos编辑器里了，明后天改改loader部分。
（我只是在这个贴里提些希望而已。。让多多公开接口，hook，event。。。。说白了和我的项目无关）
》cocos的源码过于松散，可以称之为anyscript。as需要的是强类型，强类型不等于静态类型。cocos的大量写法本身并不具备通过asc编译成wasm的能力
引擎组的人如果想把引擎重构一下编译我当然支持。
但是我这边是利用者，我需要保护的是我这边的业务逻辑，当然业务逻辑里也有不重要的，不重要的就ts转js后加的混淆就可以了。重要的一部分class，计算，数据，都可以直接一开始创建文件时就建为.as文件，如果规定好里面的命名什么的，和一般使用应用应该没什么差别。
当然引擎组能把cocos引擎这边也wasm化了的话，那当然更好。
为什么不用脚手架什么什么的，.ts怎么通过cocos后台编译成.js的呢？用相同的办法就可以了。把.as拖入cocos编辑器，然后编辑器后台转换，之后就会在lib import那里找到对应的.wasm了。
过去有一个coffeescript，但只是名字和逻辑在，把这个全部替换为assemblyscript，然后在meta里增加一个assemblyscript.js，里面进行.as到.wasm的转换就可以了。
当然这只是单个文件的转换，到要build的时候，怎么把这些wasm结合是个问题，文件会变太多的。
·（从源头的.as文件结合。。。不知道行不行）
。。。不好意思感觉太激动了，我去冷静下。。。
@jare
不好意思，我这边采取了许多不是很正规的方式，达到了把.as (assemblyscript)通过cocos内部黑盒里的文件筛选发配机制，进行了处理。实际上应该时通过消息机制和插件做这些才是正途。所以如果能公布 筛选发配机制的 hook ，并允许我们增加自定义扩展名的文件 ，就可以使用正规途径完成功能了，希望大佬能为cocos的长远打算，言辞过甚请您见谅。
ts都还没有整明白，现在又多了一个as。。。。程序员的世界还真多东西学呀。。。话说这语言和隔壁群laya 的AS又啥区别？？？？
laya的as是ActionScript，cocos这边说的是 AssemblyScript。
ActionScript原本是给Flash用的。AssemblyScript算是TypeScript的一种变种方言，因为类型强制比TypeScript更强，可以像c++，rust一样编译成 wasm（一种可以在浏览器里运行的类汇编语言）。wasm更快，而且是人看不懂的字节码，所以比较安全。wasm是未来的趋势，unity输出的网页端也是wasm。
其实AssemblyScript 用 ActionScript 的标准更好，ActionScript是基于ES4的，你要的强类型它都有，比如int ，char，byte ，当初ES4设计出来的时候被微软谷歌为首的浏览器商打压，认为设计太超前了，改追求ES5了，只有ActionScript继承ES4下来。
谢谢你的回复，不太清楚ActionScript最近的动向。。。
今天碰了许多坑，一个是是wasm.map不能读取的问题，
通过阅读资料，发现了，如果是用 WebAssembly.instantiateStreaming初始化的话，从服务器段送回的Content-Type就一定要是application/wasm，要不就会初始化失败。WebAssembly.instantiateStreaming时，要求 source maps必须时相对途径，其实这个只需要编译wasm时增加一个参数"–sourceMap"就行，后面不用设置。
https://www.assemblyscript.org/debugging.html#source-maps
今天我实验成功的就只有这个。 WebAssembly.instantiate和 Absolute source maps这个组合千万不要用，会累死人的。。。
生命在于折腾
不明觉厉 
学无止境。
感觉大家都把AssemblyScript当成玩具，现在的AssemblyScript支持的库没几个，没生态圈就没有人用。所以虽说大家都喜欢wasm，但大家真的能等到AssemblyScript生态成熟的那一天吗？
大佬在cocos里用rust的么？厉害。
刚才发现一个有趣的东西，rust写的aws sdk，然后似乎时编译成wasm
https://github.com/kryptco/rusoto-wasm-compatible
我在考虑学习省成本的问题，
rust当然编译wasm效率最高，
但rust语言毕竟困难，当然我不是说rust的这个时问题，还是，cocoscreator选择了typescirpt，所以，不去选修改个类型就能跑的AssemblyScript，却去加入rust支持，好啊，rust是好，照这么说unity的net core不是也可以编译wasm么，net core还是开源的，人家unity用的是c#，顺理成章。rust呢？好啊，让typescirpt利用者使用rust，你还是饶了他吧。
rust很有前途，我建议啊，cocoscreator团队做两手准备，
一手是全部用rust重写，版本号 CococCreator 5.0，基本和unity的c#一个模式，会保留一下js只用于postMessage之类的，wasm与js的接口，js的api也会变得极其少的。
这个CococCreator 5.0的优势就是rust的wasm是世界上最轻量的，最快的，能出来的话，肯定手机端浏览器都没问题可以跑，这就统一江湖了。
还有一手是，用AssemblyScript进行重写，版本号 CococCreator 4.0，基本和unity的c#一个模式，纯js只用于postMessage之类的，wasm的编译，可以在typescirpt的类型强制下解决，比起rust的语法复杂，AssemblyScript还是较为简单的，
这个CococCreator 5.0的优势就是，在开发过程中，能深入理解typescript和AssemblyScript，稍微改下说不定就可以用，不用rust的大费周章。
我个人的已经，毕竟大家都是喜欢前端的，rust这个可以编译wasm的语言出现了，但大部分人可以说这个和他没关系，他们只需要javascript/typescirpt,就可以了，说的意思就是，rust的大精英了，但大部分开发之不是精英人员。我们不是精英，我们只是打工卖命的。
加入过上面说，你这个代码，即使把一部分处理subpackage化后混淆了，但js的部分还是不行啊。
那么，这个是由您回去选择rust吗，你把你但精英可以，但大部分人就是懒惰，就是不愿意更新认知，所以对于他们来说，AssemblyScript给了他们一些小小的期待，
我不知道cocos官方怎么想的，定方向是也要考虑这些啊。
反正cocos官方已经有过，强制typescirpt的先例的，以后强制rust或这个AssemblyScript也没什么大事。
但事事的首部中，虽然对于cocos内部的资源可能分散了，但其实rust版本的CococCreator 5.0，和AssemblyScript的CococCreator 5.0，就当是我的痴心妄想，可以期待一下的吧。
关于AssembyScript的生态环境问题，我觉得在各大sdk的项目提一下issues也算是不过分的。
·（·英语差请见谅）
https://github.com/aws/aws-sdk-js-v3/issues/2186
官方花了4，5年用typescript重写了引擎，现在又要用rust重写，23333