ConfigService优于dotenv

Question

使用@NestJS/Config而不是使用dotenv检索envvar有什么好处(或缺点)？在这两种情况下，我都可以创建一个负责所有envvars的类，但我应该这样做吗？

我知道@NestJS/Config在窗帘后面使用dotenv，但是有什么理由让一个选择而不是另一个呢？

Answer 1

两大优点是能够使用Joi或类验证器或任何您想要的模式验证器，以确保您的env值在运行时访问它们和获得错误之前都是正确的。更早的反馈循环意味着以后失败的次数更少。另一个最大的优点是使用DI，这意味着在测试用例中更容易(通常)模拟env变量值，而不必将其赋值给process.env本身。还有一些速度上的改善，因为Nest缓存了值，所以如果您再次读取它，您不需要从process.env读取，但除此之外，没有太多可提及的。如果你不想使用它，不要觉得你必须使用它。还有一个缺点，就是不能在装饰器中使用ConfigService。

Answer 2

我的理解是，使用@nestjs/config很容易将您的配置/envvars作为项目中的一个模块来管理。因此，它可以很容易地在不同的地方交换：

例如，如果您需要一组不同的配置来进行测试，则不必实际修改process.env.xxx或使用不同的.env文件。

但是，如果这样做，还需要所有/大多数其他服务来利用这个模式。如果所有其他服务都是纯函数导出，就不会有多大帮助了。