Ответ 1

Вопрос

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

Ответ

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

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

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

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

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

В целом, я бы сказал, что это действительно разработчик.

Ответ 2

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

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

Ответ 3

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

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

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

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

Ответ 4

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

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

Ответ 5

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

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