Это в значительной степени сводится к личным предпочтениям и условностям используемых вами фреймворков. Это просто разные форматы для хранения одной и той же информации.

Некоторые примеры форматов файлов конфигурации:

• .env
• *.yml (файлы YAML)
• *.ini (обычно только для Windows)
• *.json

В конце концов, все они выполняют одну и ту же цель: предоставляют вашему приложению информацию, относящуюся к среде (учетные данные, пути к файлам, строки подключения и т. д.). Выберите формат, который лучше всего соответствует вашему выбору фреймворка.

Файлы .env обычно используются для хранения информации, относящейся к конкретной среде развертывания, в то время как файлы config.json могут использоваться для хранения данных, относящихся к приложению в целом.

любой подход работает, и то, хранятся ли ваши файлы конфигурации в вашем репозитории, больше зависит от того, должны ли данные быть конфиденциальными.

Я думаю, это действительно зависит от вас, важно помнить, почему вы используете этот подход. Идея состоит в том, чтобы сохранить ваши конфиденциальные данные в файле, который не будет передан в систему управления версиями или в любое другое место, кроме вашей локальной среды - это обеспечивает безопасность данных. Затем, когда вы будете готовы к развертыванию на удаленном сервере, вам необходимо вручную вставить эти значения в эту среду.

Обычно я использую .env, потому что синтаксис для получения данных из файла .env поддерживается во многих удаленных средах, таких как heroku. Когда я развертываю приложение на heroku, я могу зайти в настройки приложения и ввести переменные среды с помощью пользовательского интерфейса панели управления heroku - мне не нужно выяснять, как создать файл json вручную и т. д. (возможно, есть другие обходные пути). После того, как переменные установлены, я просто использую process.env.variableName для доступа к данным.

Вопрос

Когда следует использовать .env вместо config.json и для чего?

Ответ

Это довольно сложный ответ. С одной стороны, вам следует использовать любой из этих инструментов только во время разработки. Это означает, что в производственной или производственной среде вы должны добавить эти переменные непосредственно в среду:

NODE_ENV=development node ./sample.js --mongodb:host "dharma.mongohq.com" --mongodb:port 10065

По сути, нет явного победителя над другим, поскольку они оба полезны по-разному. Вы можете иметь вложенные данные с config.json, но, с другой стороны, вы также можете иметь более чистую структуру данных с .env.

Также следует отметить, что вы никогда не хотите передавать эти файлы в систему управления версиями (git, svc и т. д.).

С другой стороны, эти инструменты позволяют новичкам быстро приступить к работе, не беспокоясь о том, как установить переменные среды и различия между средой Windows и средой Linux.

В общем, я бы сказал, что все зависит от разработчика.

Статистическое сравнение двух пакетов NPM (наряду с другими подобными решениями) может быть лучшим способом решить для себя.

На момент написания этой статьи dotenv - это гораздо меньший пакет с большей поддержкой (не считая фактических участников, только исходя из количества оставшихся проблем и огромной популярности). Он также новее на 2,5 года и, если фанфары важны для вас, в нем вдвое больше звезд.