Как настроить NODE_ENV для производства / разработки в OS X

Ответы:

664

Перед запуском приложения вы можете сделать это в консоли,

export NODE_ENV=production

Или, если вы находитесь в Windows, вы можете попробовать это:

SET NODE_ENV=production

или вы можете запустить свое приложение так:

NODE_ENV=production node app.js

Вы также можете установить его в своем файле JS:

process.env.NODE_ENV = 'production';

Но я не предлагаю делать это в вашем исполняемом файле, так как нелегко открыть VIM на вашем сервере и изменить его на рабочий. Вы можете создать файл config.json в своем каталоге, и каждый раз, когда ваше приложение запускается, оно читает из него и устанавливает конфигурацию.

Фарид Нури Нешат
источник
12
Это плохой совет. Это будет сложно установить process.env.NODE_ENVнадежно из самого приложения. Лучше всего правильно установить переменную окружения, как это описано ниже.
МК Сафи
15
Я фанат настройки NODE_ENVявно каждый раз, когда вы запускаете приложение, как во втором примере ( NODE_ENV=production node app.js). Таким образом, вы потенциально спасете себя от будущих затяжек, если вы забудете NODE_ENVвернуть себе местный уровень development.
Джон
Совсем не блестяще. Каждый раз, когда вы запускаете свое приложение, вы должны добавить этот env var. Это отстой. Ниже выложено лучшее решение.
Лукас Лиезис
2
Обратитесь к npmjs.com/package/cross-env для простого кроссплатформенного решения. cross-env NODE_ENV=productionработает на Windows и Linux / Mac.
AntonB
1
@ Глеб NODE_ENV=production forever app.jsдолжен работать.
Фарид Нури Нешат
102

в package.json:

{
  ...
  "scripts": {
    "start": "NODE_ENV=production node ./app"
  }
  ...
}

затем запустите в терминале:

npm start
Таро Алан
источник
1
не начинайте помещать кучу скриптов в package.json, это плохая практика, потому что вы вносите несоответствия и убивает неизменность в ваших проектах. Я знаю, что многие люди создают сценарии для выполнения ворчания или глотка, но не делают этого
PositiveGuy
38
@WeDoTDD о чем ты говоришь? Эти сценарии предназначены для использования аналогично тому, как работает make-файл. Использование его в качестве этого примера или как вы упомянули для запуска gulp - вполне разумный вариант использования. Для простых задач я теперь даже не использую gulp и делаю все это внутри скрипта, гораздо быстрее заставить все работать, и я позволяю webpack делать ту работу, которая раньше выполнялась gulp.
Марко Грешак
15
@WTF - Что вы имеете в виду, что это «плохая практика» - использовать скрипты в package.json? В этом смысл сценария: раздел, чтобы поставить сценарии! Это совершенно справедливо и устраняет необходимость глотать или ворчать. Все сделано через команду и веб-пакет.
TetraDev
6
@WTF Использование сценариев значительно улучшает согласованность. Вы можете настроить стандартный набор команд, которые будут использоваться в нескольких проектах, которые могут не использовать одни и те же базовые сценарии сборки, библиотеки и т. Д. Вы можете, по крайней мере, попытаться подтвердить свою точку зрения фактами и примерами.
Льюис Даймонд
4
Помещение NODE_ENV=productionв package.json не имеет особого смысла. Запуск npm startв разработке запустит его в производство. Вы можете написать свой код так, как будто он всегда производственный, поскольку вы всегда выполняете его таким образом. Единственная причина, по которой я это делаю, - заставить другие модули (например, Express) работать в производственном режиме. Зачем вообще использовать переменные среды, если они никогда не меняются?
Nateowami
65

.envЗдесь еще никто не упоминается ? Создайте .envфайл в корне вашего приложения, затем require('dotenv').config()и прочитайте значения. Легко меняется, легко читается, кроссплатформенный.

https://www.npmjs.com/package/dotenv

Томас МакКейб
источник
1
Странно, никто не упоминает об этом, лучшее решение на мой взгляд. Поместите имя среды в тот же файл с остальными переменными.
Асинус Рекс
2
Установка NODE_ENV в файле .env не будет работать. Смотрите это: github.com/motdotla/dotenv/issues/328
Михаил Зеленский,
У меня установка "mode": "production"в .envфайле сработала.
DarkLite1
46

export NODE_ENV=production плохое решение, оно исчезает после перезагрузки.

если вы не хотите больше беспокоиться об этой переменной - добавьте ее в этот файл:

/etc/environment

не используйте синтаксис экспорта, просто напишите (в новой строке, если какой-то контент уже есть):

NODE_ENV=production

работает после перезагрузки. Вам больше не нужно будет никуда вводить команду export NODE_ENV = production и просто использовать узел с чем угодно - навсегда, pm2 ...

За героку:

heroku config:set NODE_ENV="production"

который на самом деле по умолчанию.

Лукас Лиесис
источник
2
Технический кошмар. А как насчет коробки, где у вас нет прав доступа к / etc?
Томас МакКейб,
1
Я лично использую NODE_ENV=production gulp bundle-production-appдля связывания готовый сценарий, на сервере NODE_ENV находится в среде сервера, а на машине разработчика его нет. На некоторых машинах это кошмар, если он не установлен, и вы ожидаете, что он будет установлен всегда . В некоторых вы ожидаете, что его не будет, поэтому не добавляйте. В любом случае, делая пользовательский интерфейс, я ясно даю понять, находится ли он в режиме разработки, чтобы у вас никогда не возникало вопросов, включен он или нет. Если NODE_ENV - это! == производство, то, по вашему мнению, вы находитесь в другом режиме, так что никакого кошмара нет. Все ясно, все хорошо.
Лукас Лиезис
+1 за разговор о том, как сделать так, чтобы он сохранялся. Интересно, сколько людей установили его только на текущей сессии, думая, что оно сохранится. Как насчет перед перезагрузкой? Если вы хотите установить его сразу, вы должны вставить его /etc/environment и запустить export NODE_ENV=production?
Nateowami
24

Чтобы не беспокоиться о том, выполняете ли вы свои сценарии в Windows, Mac или Linux, установите пакет cross-env . Тогда вы можете легко использовать свои скрипты, например:

"scripts": {
    "start-dev": "cross-env NODE_ENV=development nodemon --exec babel-node -- src/index.js",
    "start-prod": "cross-env NODE_ENV=production nodemon --exec babel-node -- src/index.js"
}

Массивные реквизиты для разработчиков этого пакета.

npm install --save-dev cross-env
Пресловутый
источник
22
heroku config:set NODE_ENV="production"
david_adler
источник
2
аааа это то что мне нужно ты потрясающий
Коннор Лич
5
NODE_ENV=productionтеперь по умолчанию в Heroku развертывается node.js.
Sean
1
Heroku - не единственное место для развертывания
Паван Катепалли
9

Для Windows Powershell используйте эту команду

$env:NODE_ENV="production" ; node app.js
Харикришнан
источник
6

На OSX я бы порекомендовал добавить export NODE_ENV=developmentв ваш ~/.bash_profileи / или ~/.bashrcи / или ~/.profile.

Лично я добавляю эту запись в мой ~/.bashrcи затем получаю~/.bash_profile ~/.profile импорт содержимого этого файла, чтобы он был одинаковым для всех сред.

После внесения этих изменений обязательно перезагрузите терминал, чтобы выбрать настройки.

Винчил Бишоп
источник
2

Если вы находитесь на окнах. Откройте ваш cmd в правой папке, затем сначала

set node_env={your env name here}

нажмите Enter, тогда вы можете начать свой узел с

node app.js

это начнется с вашей настройки env

garenyondem
источник
1
он не исчезнет после перезагрузки? У меня нет окон, я не могу попробовать себя.
Лукас Лиезис
Если вы спрашиваете о перезапуске узла no, он не исчезнет, ​​пока вы полностью не закроете командную строку. Но если Windows Server перезагружается, он исчезнет.
garenyondem
2
говорить о перезагрузке ОС. Вот почему мне лучше найти другой способ перестать интересоваться каждый раз, когда устанавливаются обновления Windows, или просто перезагружать эту проблему снова и снова.
Лукас Лиезис
2

Если вы используете webpack в своем приложении, вы можете просто установить его там, используя DefinePlugin...

Итак, в вашем pluginразделе установите NODE_ENV на production:

plugins: [
  new webpack.DefinePlugin({
    'process.env.NODE_ENV': '"production"',
  })
]
Алиреза
источник
1

Чтобы иметь несколько сред, вам нужны все ответы раньше (параметр NODE_ENV и его экспорт), но я использую очень простой подход без необходимости что-либо устанавливать. В ваш package.json просто поместите скрипт для каждой нужной вам среды, например:

...
"scripts": {
    "start-dev": "export NODE_ENV=dev && ts-node-dev --respawn --transpileOnly ./src/app.ts",
    "start-prod": "export NODE_ENV=prod && ts-node-dev --respawn --transpileOnly ./src/app.ts"
  }
 ...

Затем, чтобы запустить приложение вместо npm startиспользования npm run script-prod.

В коде вы можете получить доступ к текущей среде с process.env.NODE_ENV.

Вуаля.

rmpt
источник
NODE_ENV должен быть либо "разработкой", либо "производством", вышеупомянутое не распознается сторонним кодом (хотя вы можете посмотреть на process.env для него)
Джон Калвинер
1

Windows CMD -> set NODE_ENV=production

Windows Powershell -> $env:NODE_ENV="production"

MAC -> export NODE_ENV=production

Джанит Удара
источник
0

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

Для тех, кто использует экспресс. Вы можете использовать Grunt-Express-сервер, который также является фантастическим. https://www.npmjs.org/package/grunt-express-server

Джесси
источник
0

Это может быть шанс, что вы сделали два экземпляра объекта sequelize

например: var con1 = new Sequelize (); var con2 = new Sequelize ();

чем то же самое произойдет ошибка

Прахар Диксит
источник