Как установить некоторые переменные окружения в package.json для использования с командами npm start?
Вот что у меня сейчас есть в моем package.json:
{
...
"scripts": {
"help": "tagove help",
"start": "tagove start"
}
...
}
Я хочу установить переменные окружения (например, NODE_ENV) в сценарии запуска, при этом все еще имея возможность запустить приложение с помощью только одной команды, npm start.
Установите переменную среды в команде сценария:
...
"scripts": {
"start": "node app.js",
"test": "NODE_ENV=test mocha --reporter spec"
},
...
Затем используйте process.env.NODE_ENV в своем приложении.
Примечание: это только для Mac и Linux. Для Windows обратитесь к комментариям.
Просто используйте пакет NPM Cross-Env. Супер просто. Работает на Windows, Linux и во всех средах. Обратите внимание, что вы не используете && для перехода к следующей задаче. Вы просто устанавливаете env и затем запускаете следующую задачу. Благодарим @mikekidder за предложение в одном из комментариев здесь.
Из документации:
{
"scripts": {
"build": "cross-env NODE_ENV=production OTHERFLAG=myValue webpack --config build/webpack.config.js"
}
}
Обратите внимание, что если вы хотите установить несколько глобальных переменных, вы просто должны указать их последовательно, а затем выполнить команду.
В конечном счете, команда, которая выполняется (используя spawn):
webpack --config build/webpack.config.js
NODE_ENV окружения NODE_ENV будет установлена перекрестным env
Я просто хотел добавить свои два цента сюда для будущих исследователей узлов. В моем Ubuntu 14.04 NODE_ENV=test не работал, мне пришлось использовать export NODE_ENV=test после которого NODE_ENV=test тоже начал работать, странно.
В Windows, как уже было сказано, вы должны использовать set NODE_ENV=test но для кроссплатформенного решения библиотека кросс-env, похоже, не сработала, и вам действительно нужна библиотека для этого:
export NODE_ENV=test || set NODE_ENV=test&& yadda yadda
Вертикальные export NODE_ENV необходимы, так как в противном случае Windows export NODE_ENV команде export NODE_ENV: D. Не знаю, о том, что нужно сделать, но я тоже их убрал.
Поскольку я часто нахожу себя работающим с несколькими переменными окружения, я считаю полезным хранить их в отдельном файле .env (не .env на это внимания из вашего контроля .env).
VAR_A=Hello World
VAR_B=format the .env file like this with new vars separated by a line break
Затем добавьте export $(cat.env | xargs) && перед командой сценария.
Пример:
{
...
"scripts": {
...
"start": "export $(cat .env | xargs) && echo do your thing here",
"env": "export $(cat .env | xargs) && env",
"env-windows": "export $(cat .env | xargs) && set"
}
...
}
Для теста вы можете просмотреть переменные env, запустив npm run env (linux) или npm run env-windows (windows).
вдруг я обнаружил, что actionhero использует следующий код, который решил мою проблему, просто передав --NODE_ENV=production в стартовый скрипт.
if(argv['NODE_ENV'] != null){
api.env = argv['NODE_ENV'];
} else if(process.env.NODE_ENV != null){
api.env = process.env.NODE_ENV;
}
Я был бы очень признателен, если бы принял ответ от кого-то другого, кто знает, как лучше установить переменные окружения в package.json или сценарии инициализации или что-то вроде того, где приложение загружается кем-то другим.
Попробуйте это в Windows, заменив YOURENV:
{
...
"scripts": {
"help": "set NODE_ENV=YOURENV&& tagove help",
"start": "set NODE_ENV=YOURENV&& tagove start"
}
...
}
Хотя я не отвечаю прямо на вопрос, я хотел бы поделиться идеей поверх других ответов. Из того, что я получил, каждый из них мог бы предложить некоторый уровень сложности для достижения кроссплатформенной независимости.
В моем сценарии все, что я хотел, первоначально, чтобы установить переменную для контроля, защищать ли сервер с помощью аутентификации JWT (для целей разработки)
Прочитав ответы, я решил просто создать 2 разных файла с включенной и выключенной аутентификацией соответственно.
"scripts": {
"dev": "nodemon --debug index_auth.js",
"devna": "nodemon --debug index_no_auth.js",
}
Файлы - это просто оболочки, которые вызывают исходный файл index.js (который я переименовал в appbootstrapper.js):
//index_no_auth.js authentication turned off
const bootstrapper = require('./appbootstrapper');
bootstrapper(false);
//index_auth.js authentication turned on
const bootstrapper = require('./appbootstrapper');
bootstrapper(true);
class AppBootStrapper {
init(useauth) {
//real initialization
}
}
Возможно, это может помочь кому-то еще
Для большего набора переменных среды или для повторного их использования вы можете использовать env-cmd.
Файл ./.env:
# This is a comment
ENV1=THANKS
ENV2=FOR ALL
ENV3=THE FISH
./package.json:
{
"scripts": {
"test": "env-cmd mocha -R spec"
}
}
Вы не должны устанавливать переменные ENV в package.json. Actionhero использует NODE_ENV, чтобы вы могли изменять параметры конфигурации, которые загружаются из файлов в ./config. Просмотрите redis config file и посмотрите, как NODE_ENV использует для изменения параметров базы данных в NODE_ENV=test
Если вы хотите использовать другие переменные ENV для настройки (возможно, HTTP-порт), вам все равно ничего не нужно менять в package.json. Например, если вы установите PORT=1234 в ENV и хотите использовать это как порт HTTP в NODE_ENV=production, просто ссылайтесь на него в соответствующем файле конфигурации IE:
# in config/servers/web.js
exports.production = {
servers: {
web: function(api){
return {
port: process.env.PORT
}
}
}
}
{
...
"scripts": {
"start": "ENV NODE_ENV=production someapp --options"
}
...
}
Это будет работать в консоли Windows:
"scripts": {
"aaa": "set TMP=test && npm run bbb",
"bbb": "echo %TMP%"
}
npm run aaa
вывод: test
Смотрите этот ответ для деталей.
Используйте cross-env и его довольно легко использовать.