dotenv 是否与十二要素 App 相矛盾？
Does dotenv contradict the Twelve-Factor App?
我已阅读有关 Twelve Factor App's Config - Section III and searched for a way to do it in NodeJS. It seems that most people recommend dotenv 在环境变量中存储配置的信息。
然而，dotenv 似乎与十二因素应用程序相矛盾，如所述：
Another approach to config is the use of config files which are not checked into revision control, such as config/database.yml in Rails. This is a huge improvement over using constants which are checked into the code repo, but still has weaknesses: it’s easy to mistakenly check in a config file to the repo; there is a tendency for config files to be scattered about in different places and different formats, making it hard to see and manage all the config in one place. Further, these formats tend to be language- or framework-specific.
The twelve-factor app stores config in environment variables (often shortened to env vars or env). Env vars are easy to change between deploys without changing any code; unlike config files, there is little chance of them being checked into the code repo accidentally; and unlike custom config files, or other config mechanisms such as Java System Properties, they are a language- and OS-agnostic standard.
理解这个语句，似乎使用 dotenv，您将创建一个配置文件 .env，然后将它们导出为环境变量。
这不会违反十二要素应用程序吗，因为 .env 文件可能会被意外签入代码库？
大多数版本控制系统都有忽略某些文件的方法。
Git 有 .gitignore
SVN 有 "Special Ignores"
附带说明一下，这些技术同样用于忽略 node_modules 目录以避免不必要的文件复制。
12factor 在有人真正提交并推动 .env 之前不会被违反；）
.env 文件也可以存储在 repo 本身之外，因为库或应用程序仍然必须读取 .env 文件并将变量推送到环境中。根据您的实施，这可以像将路径从 ".env" 更改为 "../.env".
一样简单
使用 .env 文件可能是一个很好的折衷方案，允许开发人员轻松管理环境，但在部署期间仍与更好的环境实践兼容。我可能在虚拟机中有 30-40 个 12factor-flavored 应用程序 运行，如果没有像 .env.
这样的 "shim"，必须单独管理每个环境是令人生畏的
OP 问了一个深思熟虑的问题。
我会说 dotenv 与第 3 节的 12 因素相矛盾，原因有两个。
根据定义，即这一段：“另一种配置方法是使用未签入版本控制的配置文件，......仍然有弱点：它很容易错误地将配置文件签入 repo; ...（因此 12 因素应用程序使用不同的方法）将配置存储在环境变量中”，现在你明白了，只是因为 .env 文件 could/should 在 .gitignore 中声明，不会使 dotenv 免于“容易错误地将配置文件签入回购协议”的审查。
如果应用从 且仅从 env var 读取配置，则该应用可以完全符合第 3 节的 12 因素。但是 dotenv 的一个功能是允许应用程序自动提取 ./.env（如果可用）。从这个意义上说，.env 文件 - 尽管它的名称具有欺骗性 - IS 是一个配置文件，贯穿始终。同样，这属于 12 因素明确避免的配置方法类别。
话虽如此，dotenv 仍然是可行的选择之一。其他选项包括：管理 docker 层中的环境变量；或者在 unix 用户的 .*rc 文件中；或在网络服务器配置中；或在 /etc/profile 中（引自 ）。 dotenv 提供了一种最通用的文件格式（fwiw，docker env_file 同样简单，尽管它们的规格不同），但是 dotenv 是唯一“污染”的解决方案目标应用程序的代码库多了一个依赖项。
底线，dotenv 很好，有趣的是许多 dotenv 实现继承了它从 12-factor app 宗旨开始的说法，但只有少数人承认它 .env 方法偏离了 12 因素应用程序。
我已阅读有关 Twelve Factor App's Config - Section III and searched for a way to do it in NodeJS. It seems that most people recommend dotenv 在环境变量中存储配置的信息。
然而，dotenv 似乎与十二因素应用程序相矛盾，如所述：
Another approach to config is the use of config files which are not checked into revision control, such as config/database.yml in Rails. This is a huge improvement over using constants which are checked into the code repo, but still has weaknesses: it’s easy to mistakenly check in a config file to the repo; there is a tendency for config files to be scattered about in different places and different formats, making it hard to see and manage all the config in one place. Further, these formats tend to be language- or framework-specific.
The twelve-factor app stores config in environment variables (often shortened to env vars or env). Env vars are easy to change between deploys without changing any code; unlike config files, there is little chance of them being checked into the code repo accidentally; and unlike custom config files, or other config mechanisms such as Java System Properties, they are a language- and OS-agnostic standard.
理解这个语句，似乎使用 dotenv，您将创建一个配置文件 .env，然后将它们导出为环境变量。
这不会违反十二要素应用程序吗，因为 .env 文件可能会被意外签入代码库？
大多数版本控制系统都有忽略某些文件的方法。
Git 有 .gitignore
SVN 有 "Special Ignores"
附带说明一下，这些技术同样用于忽略 node_modules 目录以避免不必要的文件复制。
12factor 在有人真正提交并推动 .env 之前不会被违反；）
.env 文件也可以存储在 repo 本身之外，因为库或应用程序仍然必须读取 .env 文件并将变量推送到环境中。根据您的实施，这可以像将路径从 ".env" 更改为 "../.env".
使用 .env 文件可能是一个很好的折衷方案，允许开发人员轻松管理环境，但在部署期间仍与更好的环境实践兼容。我可能在虚拟机中有 30-40 个 12factor-flavored 应用程序 运行，如果没有像 .env.
OP 问了一个深思熟虑的问题。
我会说 dotenv 与第 3 节的 12 因素相矛盾，原因有两个。
根据定义，即这一段：“另一种配置方法是使用未签入版本控制的配置文件，......仍然有弱点：它很容易错误地将配置文件签入 repo; ...（因此 12 因素应用程序使用不同的方法）将配置存储在环境变量中”，现在你明白了，只是因为
.env文件 could/should 在.gitignore中声明，不会使 dotenv 免于“容易错误地将配置文件签入回购协议”的审查。如果应用从 且仅从 env var 读取配置，则该应用可以完全符合第 3 节的 12 因素。但是 dotenv 的一个功能是允许应用程序自动提取
./.env（如果可用）。从这个意义上说，.env文件 - 尽管它的名称具有欺骗性 - IS 是一个配置文件，贯穿始终。同样，这属于 12 因素明确避免的配置方法类别。
话虽如此，dotenv 仍然是可行的选择之一。其他选项包括：管理 docker 层中的环境变量；或者在 unix 用户的 .*rc 文件中；或在网络服务器配置中；或在 /etc/profile 中（引自 dotenv 提供了一种最通用的文件格式（fwiw，docker env_file 同样简单，尽管它们的规格不同），但是 dotenv 是唯一“污染”的解决方案目标应用程序的代码库多了一个依赖项。
底线，dotenv 很好，有趣的是许多 dotenv 实现继承了它从 12-factor app 宗旨开始的说法，但只有少数人承认它 .env 方法偏离了 12 因素应用程序。