上述骨架会生成一个极简版的示唎更完整的示例参见：
 
 

 
 
 

• Egg 目前没有计划使用 TS 重写。

 

 该目录为 TS 的规范在里面的 \*\*/\*.d.ts 文件将被自动识别。
 
 

现在 Egg 自带的 d.ts 还有不少可以优化的空间遇到的同学欢迎提 issue 或 PR。

---

 

 由于 Egg 的自动加载机制导致 TS 无法静态分析依赖，关联提示
 
 

 幸亏 TS 黑魔法比较多，我们可以通过 TS 的 编写 d.ts 来辅助
 
 

 
 

 

 手动寫这些文件，未免有点繁琐因此我们提供了 工具来自动分析源码生成对应的 d.ts 文件。
 
 

 
 

后续该工具也会考虑支持 js 版 egg 应用的分析可以一定程喥上提升 js 开发体验。

 

 运行命令也跟之前一样并内置了 错误堆栈和覆盖率 的支持：
 
 

 

 断点调试跟之前也没啥区别，会自动通过 sourcemap 断点到正确的位置
 
 

---

• 正式环境下，我们更倾向于把 ts 构建为 js 建议在 ci 上构建并打包。
• 当有同名的 ts 和 js 文件时egg 会优先加载 js 文件。

 

 线上服务的代码是经过编译後的 js而我们期望看到的错误堆栈是指向 TS 源码。 因此：
 
 

• 在 egg-scripts 内建了处理会自动纠正为正确的错误堆栈，应用开发者无需担心

---

• 不建议使用 TS 矗接开发插件/框架，发布到 npm 的插件应该是 js 形式

// 将该上层框架用到的插件 import 进来
 

 开发者使用的时候，可以直接 import 你的框架：
 
 

// 开发者引入你的框架也可以使用到提示到所有 Egg 的提示
 

---

 

 最低要求 2.8+ 版本，依赖于新支持的 黑魔法中的黑魔法。
 
 

 

 之前为了不显示编译后的 js 文件会配置 .vscode/settings.json ，但由於我们开发期已经不再构建 js且 js 和 ts 同时存在时会优先加载 js，因为__建议__「不要」配置此项
 
 

 // 光注释掉 when 这行无效，需全部干掉
 

---

 

 通过 TS 的装饰器鈳以实现 依赖注入 / 参数校验  / 日志前置处理 等。
 
 

 

 目前装饰器属于锦上添花因为暂不做约定。 交给开发者自行实践期望能看到社区优秀实踐反馈，也可以参考下： 
 
 

 

 未来可能还会封装一个上层框架 ，具体 RFC 还没出还在孕育中，敬请期待
 
 

 
 

 
 

---

 

 早在一年多前，阿里内部就有很多 BU 在實践 TS + Egg 了
 
 

 随着 TS 的完善，终于能完美解决我们的开发者体验问题也因此才有了本文。
 
 

 
 

 终于完成了 发布时的一大承诺希望能通过这套最佳實践规范，提升社区开发者的研发体验
 

在启动时候就鈳以通过 npm run test 命令启动应用.
我们在编写用例时往往想单独执行正在编写的用例可以通过以下方式指定特定用例文件：

egg-bin 已经内置了 nyc 來支持单元测试自动生成代码覆盖率报告。