用PuerTS时遇到debugpath、tsc、sourcemap等问题怎么办？
PuerTS v2发布预览后，接下来我做了一个包，puerts-ts-loader做它主要是两点原因：
[*] 解决社区中高频呈现的Typescript相关疑问
[*] 提供一个第三方包规范
<hr/>解决社区中高频呈现的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，欢迎大师使用。 不管未来puerts如何，你们作为先行者，确实值得点赞！ 加油 如果有类似的官方规范用来为在github可以用来发布整个PuerTS生态提供第三方包，比如React之类的整合进来，基本生态体系就完整了。 标准化始终是生态得以成长的关键
页:
[1]