206
Do użytku w środowiskach express.js. Jakieś sugestie?Jak ustawić NODE_ENV do produkcji/rozwoju w OS X
A
Odpowiedz
426
Przed uruchomieniem aplikacji, można to zrobić w konsoli
export NODE_ENV=production
Lub jeśli jesteś w oknach można spróbować to:
SET NODE_ENV=production
lub można uruchomić aplikację tak:
NODE_ENV=production node app.js
można również ustawić go w pliku jS:
process.env.NODE_ENV = 'production';
Ale nie sugeruję robić tego w pliku runtime, ponieważ nie jest łatwo otworzyć VIM na serwerze i zmienić go na produkcyjny. Możesz utworzyć plik config.json w swoim katalogu i za każdym razem, gdy aplikacja będzie działać, odczytuje z niego i ustawia konfigurację.
20
To jest dobry artykuł o NODE_ENV: http://www.hacksparrow.com/running-express-js-in-production-mode.html.
Do automatycznego ustawienia z Grunt można użyć wtyczki https://npmjs.org/package/grunt-env.
21
heroku config:set NODE_ENV="production"
+1
ahhh to jest to, czego potrzebowałem. jesteś niesamowity –
+5
'NODE_ENV = production' jest teraz domyślny w wdrożeniach Heroku node.js. – cyanbeam
+0
OP nie prosił o Heroku, ale tak czy owak, dziękuję! –
0
Daniel ma fantastyczną odpowiedź, która jest lepszym podejściem do prawidłowego procesu wdrażania (ustaw i zapomnij).
Dla osób korzystających z ekspresu. Możesz użyć gruntowego serwera ekspresowego, który również jest fantastyczny. https://www.npmjs.org/package/grunt-express-server
67
w package.json:
{
...
"scripts": {
"start": "NODE_ENV=production node ./app"
}
...
}
następnie uruchomić w terminalu:
npm start
+1
, nie zaczynaj umieszczać pęczków skryptów w pakiecie.json, jest to zła praktyka, ponieważ wprowadzasz niespójności i zabijasz niezmienność w twoich projektach. Wiem, że wielu ludzi tworzy skrypty, by uruchomić pomruk lub łyk, ale nie rób tego – PositiveGuy
+33
@WeDoTDD o czym ty mówisz? Skrypty te mają być używane podobnie jak plik Makefile. Używanie go jako przykładu lub jak wspominałeś o uruchomieniu gulp jest całkowicie rozsądnym przypadkiem użycia. W prostych zadaniach nie używam nawet haustów i robię to wszystko w skrypcie, znacznie szybciej pracuję, a ja pozwalam, aby webpack wykonywał pracę, którą wcześniej robił gulp. –
+1
Ponieważ kończy się niespójne skrypty we wszystkich projektach, który jest koszmar utrzymania – PositiveGuy
35
export NODE_ENV=production jest złe rozwiązanie, to znika po ponownym uruchomieniu.
jeśli chcesz, aby nie martwić się o tym już zmiennej - dodać do tego pliku:
/etc/environment
nie używać składni eksportowej, wystarczy napisać (w nowej linii, jeśli niektóre treści już tam jest):
NODE_ENV=production
działa po ponownym uruchomieniu. Nie będzie musiał ponownie wprowadzić eksport NODE_ENV = produkcja polecenie już wszędzie i po prostu korzystać z węzła cokolwiek chcesz - zawsze, PM2 ...
Dla Heroku:
heroku config:set NODE_ENV="production"
który jest rzeczywiście domyślny.
+2
Koszmar konserwacji. A co z pudełkiem, w którym nie masz uprawnień do/etc? –
+1
Osobiście używam 'NODE_ENV = production gulp-production-app' do pakowania skryptu gotowego do użycia, na serwerze NODE_ENV znajduje się w środowisku serwera, aw maszynie dev nie ma go. W niektórych maszynach jest koszmar, jeśli nie jest ustawiony i spodziewamy się, że zostanie ustawiony * zawsze *. W niektórych oczekuje się, że go nie będziesz mieć, więc nie dodajesz. W każdym razie, podczas pracy z UI, wyjaśniam, czy jest w trybie programowania, więc nigdy nie masz pytania, czy jest włączone czy wyłączone. Jeśli NODE_ENV jest! == produkcja jest w twojej twarzy, że jesteś w innym trybie, więc nie ma koszmaru w ogóle. Wszystko jasne, wszystko dobrze. –
+0
+1 za rozmowę o tym, jak sprawić, by był trwały. Zastanawiam się, ile osób ustawiło to tylko w bieżącej sesji, myśląc, że to się utrzyma. A co z * przed * ponownym uruchomieniem? Jeśli chcesz go ustawić od razu, czy powinieneś umieścić go w '/ etc/environment' * i * uruchomić' export NODE_ENV = production'? – Nateowami
0
Jeśli jesteś w systemie Windows.Otwórz cmd na prawej folderze następnie pierwszy
set node_env={your env name here}
przebojem wchodzi wtedy można rozpocząć węzła z
node app.js
rozpocznie z ENV zachodzącego
+1
nie zniknie po ponownym uruchomieniu? Nie masz okien, nie możesz sam spróbować. –
+0
Jeśli pytasz o ponowne uruchomienie węzła nie, nie zniknie, dopóki całkowicie nie zamkniesz wiersza polecenia. Ale jeśli Windows Server zrestartuje ofc, zniknie. – garenyondem
+2
mówi o ponownym uruchomieniu systemu operacyjnego. Dlatego lepiej znaleźć inny sposób, aby przestać się zastanawiać za każdym razem, gdy aktualizacje systemu Windows są zainstalowane, lub po prostu ponownie uruchomić, o tym problemie. –
26
Nikt nie wspomniał .env w jeszcze tutaj? Utwórz plik .env w katalogu głównym aplikacji, a następnie require('dotenv').config() i odczytaj wartości. Łatwo zmieniane, łatwe do odczytania, platforma krzyżowa.
5
Na OSX polecam dodanie export NODE_ENV=development do listy ~/.bash_profile i/lub ~/.bashrc i/lub ~/.profile.
Osobiście dodaję ten wpis do mojego ~/.bashrc, a następnie zaimportuję zawartość tego pliku, aby była spójna w różnych środowiskach.
Po wprowadzeniu tych dodatków, należy zrestartować terminal, aby pobrać ustawienia.
3
Windows PowerShell użyj polecenia
$env:NODE_ENV="production" ; node app.js
1
Jeśli używasz WebPACK w aplikacji, można po prostu ustawić go tam, korzystając DefinePlugin ...
Tak w sekcji plugin ustaw NODE_ENV do production:
plugins: [
new webpack.DefinePlugin({
'process.env.NODE_ENV': '"production"',
})
]
2
Aby nie martwić się, czy uruchamiasz swoje skrypty w systemie Windows, Mac lub Linux, zainstaluj pakiet cross-env. Następnie możesz łatwo używać skryptów, takich jak:
"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"
}
Masowe rekwizyty dla twórców tego pakietu.
Świetne, dzięki! –
To jest zła rada. Trudno będzie niezawodnie ustawić 'process.env.NODE_ENV' z samej aplikacji. Najlepiej ustaw poprawnie swoją zmienną środowiskową, tak jak Daniel poniżej. –
Jestem fanem ustawiania 'NODE_ENV' jawnie przy każdym uruchomieniu aplikacji, tak jak w drugim przykładzie (' NODE_ENV = production node app.js'). W ten sposób potencjalnie uratujesz się przed jakimś szykowaniem się na przyszłość w przypadku, gdy zapomnisz ustawić swój lokalny 'NODE_ENV' z powrotem na' development'. – Jon