我为什么要写TSLoader

先说结论，两点：

• 解决社区中高频出现的Typescript相关疑问

• 提供一个第三方包规范

---

解决社区中高频出现的Typescript相关疑问

普洱项目组有一个重要理念：对于不同项目组会有不同实现的功能，普洱一概不提供。一是为了保证普洱的灵活性，二也是控制我们自身的开发成本。

因此，典型的比如JS加载方面，普洱只提供了ILoader和DefaultLoader；TS编译方面，普洱只提供了引擎API的dts生成。

所以，我们的群上就老是出现这些问题：

1. ILoader的debugpath是什么？怎么用？
2. vscode断点怎么打不上?（其实就是问题1）
3. ESM和CommonJS有什么区别？webpack/tsconfig里该如何配置？
4. source-map怎么支持？
5. 如何在console处实现点击ts路径跳转？
6. node_modules里的包的如何加载？

实际上，这些问题大部分都是出现在Editor下。而在Editor下，其实普洱可以考虑提供一个官方Loader。将这些问题一网打尽。

无法形成规范的第三方包结构

普洱自己的生态其实非常有潜力，有非常多的社区大佬为普洱做过贡献。但普洱的环境下，在写第三方包时有个难以处理的问题：如何在一个包里同时塞进C#和TS代码？

在没有一个统一的TS处理与加载方式时，第三方包的JS加载是个难题 ———— 使用者需要知道这个包里有什么JS脚本，给它们各自编写编译/加载逻辑。

如果每个包使用的结构不一样，其理解成本与维护成本的增长是很头痛的。

TSLoader做了什么

首先，为了解决上述问题，TSLoader提供的是一个仅Editor下的Loader。使用该Loader时，你可以直接ExecuteModule或者importTS文件，TSLoader会实时帮你执行TS编译。

其次，TSLoader还提供一套在Assets下存放ts的标准，TSLoader将每个tsconfig.json视为一个类似.asmdef的角色，将附近的ts组织起来。使用者可以直接使用TS文件相对于tsconfig的路径加载它们。如.asmdef一样，TSLoader会自动搜寻Assets下的所有tsconfig，并且你也可以额外给这个搜寻列表添加外部tsconfig。

最后，为了不影响非Editor下原有逻辑的进行，TSLoader还提供了添加子Loader的能力。这个能力能在Runtime下作用。这样TSLoader就完全不会干扰运行时逻辑。并且开发者可以链式添加多个Loader，开发者的加载逻辑可以更有条理地组织。

TSLoader使用

TSLoader目前代码和指引都在github上。puerts-webgl也已经实装了该TSLoader，欢迎大家使用。

为什么不合入主包

前面说了，TSLoader其中一个使命是为第三方模块铺路，因此它本身就率先以第三方模块的形式出现。

其次，暂时不合入主包可以保持它迭代的速度。