Як встановити змінні середовища зсередини пакету.json

Як встановити деякі змінні середовища зсередини, package.jsonякі будуть використовуватися з npm startподібними командами?

Ось що я зараз маю в своєму package.json:

{
  ...
  "scripts": {
    "help": "tagove help",
    "start": "tagove start"
  }
  ...
}

Я хочу , щоб встановити змінні оточення (як NODE_ENV) в сценарії запуску в той же час бути в змозі запустити додаток з допомогою всього однієї команди, npm start.

Встановіть змінну середовища в команді сценарію:

...
"scripts": {
  "start": "node app.js",
  "test": "env NODE_ENV=test mocha --reporter spec"
},
...

Потім використовуйте process.env.NODE_ENVу своєму додатку.

Примітка: envзабезпечує роботу на різних платформах. Ви можете пропустити це, якщо ви дбаєте лише про Mac / Linux.

Просто використовуйте пакет NPM cross-env . Супер легко. Працює в Windows, Linux та будь-яких середовищах. Зверніть увагу, що ви не використовуєте &&, щоб перейти до наступного завдання. Ви просто встановите env і потім почнете наступне завдання. Кредит @mikekidder за пропозицію в одному з коментарів тут.

З документації:

{
  "scripts": {
    "build": "cross-env NODE_ENV=production OTHERFLAG=myValue webpack --config build/webpack.config.js"
  }
}

Зауважте, що якщо ви хочете встановити кілька глобальних vars, ви просто констатуєте їх послідовно, після чого слід виконати вашу команду.

Зрештою, команда, яка виконується (використовуючи spawn), це:

webpack --config build/webpack.config.js

NODE_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

Вертикальні смуги потрібні, оскільки в іншому випадку Windows зазнає аварії на нерозпізнаній export NODE_ENVкоманді: D. Не знаю про простір, але просто, щоб переконатися, що я їх також видалив.

Оскільки я часто можу працювати з декількома змінними середовища, мені здається корисним зберігати їх у окремому .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).

Спробуйте це в Windows, замінивши YOURENV:

  {
    ...
     "scripts": {
       "help": "set NODE_ENV=YOURENV && tagove help",
       "start": "set NODE_ENV=YOURENV && tagove start"
     }
    ...
  }

раптом я виявив, що actionhero використовує наступний код, який вирішив мою проблему, просто перейшовши --NODE_ENV=productionв команду start script option.

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 або init script або щось подібне, де додаток завантажується кимось іншим.

Для більшого набору змінних середовища або коли ви хочете їх повторно використовувати, ви можете використовувати env-cmd.

./.env файл:

# This is a comment
ENV1=THANKS
ENV2=FOR ALL
ENV3=THE FISH

./package.json:

{
  "scripts": {
    "test": "env-cmd mocha -R spec"
  }
}

Хоча не відповідаючи безпосередньо на запитання, я хотів би поділитися ідеєю поверх інших відповідей. З того, що я отримав, кожен із них міг би запропонувати певний рівень складності для досягнення незалежності між платформами.

За моїм сценарієм спочатку я хотів встановити змінну для контролю того, чи захищати сервер за допомогою автентифікації 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
    }
}

Можливо, це може допомогти комусь іншому

{
  ...
  "scripts": {
    "start": "ENV NODE_ENV=production someapp --options"
  }
  ...
}

Це буде працювати в консолі Windows :

"scripts": {
  "aaa": "set TMP=test && npm run bbb",
  "bbb": "echo %TMP%"
}

npm run aaa

вихід: test

Детальну інформацію див. У цій відповіді .

Не слід встановлювати змінні ENV в package.json. actionhero використовує NODE_ENVдля зміни параметрів конфігурації, завантажених з файлів у ./config. Перевірте конфігураційний файл redis і подивіться, як 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
      }
    }
  }
}

npm (і пряжа) передає багато даних з package.json в сценарії як змінні середовища. Використовуйте, npm run envщоб побачити їх усіх. Це задокументовано в https://docs.npmjs.com/misc/scripts#environment і стосується не лише сценаріїв "життєвого циклу", prepublishа й будь-якого сценарію, виконаного npm run.

Ви можете отримати доступ до цих внутрішніх кодів (наприклад, process.env.npm_package_config_portв JS), але вони вже доступні для оболонки, що виконує сценарії, так що ви також можете отримати доступ до них як $npm_...розширення в "скриптах" (синтаксис Unix, можливо, не працює у Windows?).

Розділ "config", здається, призначений для цього використання:

  "name": "myproject",
  ...
  "config": {
    "port": "8010"
  },
  "scripts": {
    "start": "node server.js $npm_package_config_port",
    "test": "wait-on http://localhost:$npm_package_config_port/ && node test.js http://localhost:$npm_package_config_port/"
  } 

Важливою якістю цих полів "config" є те, що користувачі можуть їх замінити, не змінюючи package.json !

$ npm run start

> myproject@0.0.0 start /home/cben/mydir
> node server.js $npm_package_config_port

Serving on localhost:8010

$ npm config set myproject:port 8020
$ git diff package.json  # no change!
$ cat ~/.npmrc
myproject:port=8020

$ npm run start

> myproject@0.0.0 start /home/cben/mydir
> node server.js $npm_package_config_port

Serving on localhost:8020

Див . Документами npm config та пряжі .
Здається, що читання пряжі ~/.npmrcтак npm config setвпливає на обидва, але yarn config setпише в ~/.yarnrc, тому бачить це лише пряжа :-(

@ відповідь Луке був майже таким, який мені потрібен! Дякую.

Оскільки обрана відповідь дуже проста (і правильна), але стара, я хотів би запропонувати альтернативу імпорту змінних з окремого файлу .env під час запуску сценаріїв та виправлення деяких обмежень у відповіді Луки. Спробуйте це:

::: .env файл :::

# This way, you CAN use comments in your .env files
NODE_PATH="src/"

# You can also have extra/empty lines in it
SASS_PATH="node_modules:src/styles"

Потім у своєму пакеті json ви створите скрипт, який встановить змінні та запустить його перед потрібними сценаріями:

::: package.json :::

scripts: {
  "set-env": "export $(cat .env | grep \"^[^#;]\" |xargs)",
  "storybook": "npm run set-env && start-storybook -s public"
}

Деякі зауваження:

• Регулярний вираз у команді grep'ed cat очистить коментарі та порожні рядки.

• &&Не потрібно бути «склеєні» в npm run set-env, як це було б необхідно , якщо ви налаштовували змінні в одній команді.

• Якщо ви використовуєте пряжу, можливо, з’явиться попередження, ви можете або змінити yarn set-envабо npm run set-env --scripts-prepend-node-path &&замість цього використовувати .

Різні середовища

Ще одна перевага при його використанні полягає в тому, що ви можете мати різні змінні середовища.

scripts: {
  "set-env:production": "export $(cat .production.env | grep \"^[^#;]\" |xargs)",
  "set-env:development": "export $(cat .env | grep \"^[^#;]\" |xargs)",
}

Будь ласка, не забудьте додавати .env файли у ваше сховище git, коли у вас є ключі, паролі або чутливі / особисті дані!

використовувати git bash у windows. Git Bash обробляє команди інакше, ніж cmd.

Більшість командних підказок Windows задушаться, коли ви встановлюєте змінні середовища з NODE_ENV = виробництво таким чином. (Виняток становить Bash в Windows, який використовує нативний Bash.) Аналогічно, є різниця в тому, як команди Windows і POSIX команди використовують змінні середовища. За допомогою POSIX ви використовуєте: $ ENV_VAR, а у Windows -% ENV_VAR%. - крос-енд док

{
  ...
  "scripts": {
    "help": "tagove help",
    "start": "env NODE_ENV=production tagove start"
  }
  ...
}

використовувати пакет dotenv для оголошення змін ENV