monorepo 中唯一的 .env 文件

Question

我试图了解在单一存储库中处理环境变量的最佳方法是什么。我正在使用turborepo，项目结构被组织成 /apps 和 /packages 目录等。

项目的当前状态是应用程序/包范围内的 .env 和 .env.local 文件。包含真正秘密的文件是 .env.local，它仅保存在本地并在开发人员之间共享，而 .env 实际上是在存储库中提交的。

这个想法是只保留根级别 .env，正如 Turbo repo 和 dotenv-cli 库所建议的那样，并简化设置，但我想有更多关于我应该考虑哪些事情的想法和参考。

我自己提出的一些问题是：

我应该只使用 .env 文件并删除 .env.local 吗？
提交 .env 文件是一个好习惯吗？如果开发人员在那里添加秘密怎么办？存储库是私有的，但总的来说，提交任何 .env 文件不是一个好主意吗？
我在另一个项目中看到，根级别和项目范围的 .env.local 文件都被保留（仅包含项目特定的秘密），并且根级别 .env.local 包含存储库范围的秘密。您觉得这种做法怎么样？
如果总体目标是通过仅共享一个文件来简化开发人员的项目设置和入门，那么为什么要保留项目级别的 .env 文件？
使用 .env 和 .env.* 文件的一般做法是什么？一些库建议保留统一的 .env 文件，并且不建议使用任何其他 .env.* 文件。

感谢您的宝贵时间。

致以诚挚的问候，

我已将所有包/应用程序范围的环境变量移至根级别 .env 和 .env.local 文件中，但我想获得一些反馈以便更好地做出决定。

Answer 1

我可以分享我目前工作的地方使用的工具以及我认为最有效的工具：

对于具有可以提交、非秘密的环境变量的 .env 文件，
```
direnv
```
很棒，因为它挂接到您的 shell 中并且可以依赖于路径，允许您根据您的路径选择不同的 .envrc 文件[1]
对于秘密，有很多选择，但我真的很喜欢将 HTTP 绑定秘密放在
```
~/.netrc
```
文件中，因为像 requests.py 这样的工具会自动使用它 [2] 或在可以源/符号链接的主目录中的文件中。类似于
```
~/.kube/config
```
文件的功能 [3]
我认为首选依赖于临时凭证（例如 AWS 配置文件）的身份验证类型是存储库安全性的黄金标准，您可以为其编写帮助程序脚本，并通过环境变量引用配置文件，但您最终会从以下位置登录任何环境变量使用的范围。

将秘密内容完全保留在存储库之外的主要原因是减少意外提交它们的机会。