using
或
#include语句导入其他命名空间甚至不同程序集定义的类型时，我们基本上是在创建硬依赖关系。因此，依赖接口和 IoC 容器对于使代码更具可测试性和可维护性非常有价值。我现在正在用打字稿开发我的第一个项目。这是一个快速后端。根据我之前使用的其他语言的经验，我立即害怕广泛使用导入，认为它们也是硬依赖项，因此使我的代码不可测试。因此，我开始设计一个代码架构，该架构允许通过仅导入类型/接口并使用 tsyringe 解析它们来轻松交换模块的依赖关系（我使用了 tsyringe，但问题与我认为使用的实际容器无关）。这导致了很多样板代码，但实际上允许轻松模拟我的内部依赖项。
我现在偶然发现了
Rob Richardson 在 NDC 上的演讲关于打字稿测试中的模拟。他介绍了两个打字稿库 ts-auto-mock 和 ts-mock-imports。 ts-auto-mock 没什么特别的。接口的实际模拟不是问题。使用模拟来测试代码似乎很棘手。使用 ts-mock-imports，我们可以使不同模块进行的任何导入都使用我们的模拟。这似乎是测试任何代码所需的一切。所以现在我开始质疑 IoC 容器在使用 ts-mock-imports 等工具的打字稿中是否真的有用。
现在仍然存在代码可维护性的问题，IoC 容器可能仍然有帮助，但我实际上不确定打字稿是否就是这种情况。在我的项目中，我主要使用 IoC 容器来使我的代码可测试。TypeScript 中是否存在使用案例，如果不需要使代码可测试，IoC 容器可以让生活变得更轻松？如果我们可以随意模拟导入，还需要依赖注入吗？
ts-mock-imports 构建在 sinon 之上。在 Node.js 和浏览器中，所有测试库都提供
stubbing 功能来模拟导入的模块。由于 JS 中对象的动态特性，它们本质上交换了对象（模块）属性/方法。对于类来说很容易，但是对于在模块根部导出的变量和函数，根据 ES6 导入规范，它不应该是可行的（模块应该是只读的）；然而，大多数捆绑工具在这一点上都很宽松，因此存根根变量和函数通常仍然是可能的。
使用此类构建工具时，大多数还提供路径别名选项，可用于根据构建配置重新定位模块说明符。现在也可以直接挂钩 Node
require
机制。但 Deno 的情况可能有所不同。
虽然您可以实现自己的机制，但您可能对已经提供此功能的框架感兴趣，例如用于 Web 后端的 NestJS。它受到 Angular（前端）的启发，其中每个组件接收其请求的服务，这些服务在模块级别定义。