2016-06-13 4 views
4

zu setzen Ich versuche, ein Flag zu setzen, das meinen Code informiert, ob es in Produktion oder Entwicklung ist. Bisher habe ich gesehen:Verwirrt von, wie viele Möglichkeiten gibt, NODE_ENV

In VS-Code des launch.json:

{ "configurations": { "env": "NODE_ENV": "development" } } 

In Knoten des package.json:

{ "scripts": { "start": "NODE_ENV=production" } } 

In Webpack der webpack.config.js:

module.exports = { "plugins": new webpack.DefinePlugin({ 'process.env.NODE_ENV': '"production"' }) } 

während der Code ausgeführt wird:

NPM Pakete:

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

Powershell:

$env:NODE_ENV="production" 

Ich glaube, ich da standardmäßig nur verwirrt bin ich um 4 von derzeit diejenigen eingestellt haben. Wie genau interagieren diese? Beziehen sich alle auf die gleiche Variable? Soll ich nur eins davon haben? Welche überschreiben die anderen?

Ich würde wirklich bevorzugen, wenn es nur einen einzigen Punkt, um dies zu setzen, weil es scheint, wie jedes einzelne Modul können Sie es angeben und als Ergebnis bin ich verwirrt, wo es tatsächlich eingestellt ist. Gibt es auch einen Zugriff auf dieses Flag auf der Client-Seite oder ist es nur serverseitig?

+0

Einstellung 'Umgebungsvariable' scheint gute Ansatz, und ist unabhängig von Paketen, Modulen oder IDEs. –

+0

@MukeshSharma: Würde ich nur alle anderen hier aufgelisteten löschen? Ich denke, "React" benötigt das Webpack, damit es in der Produktion auf der Clientseite läuft. –

+0

ja, aber, wieder 'webpack' setzt' node'-umgebung, die auf server läuft. Es wurde auch hier diskutiert. https://github.com/gaearon/react-transform-boilerplate/issues/54 –

Antwort

1

In dem von Ihnen angegebenen Szenario wird die Umgebungsvariable NODE_ENV von dem Prozess initialisiert, der tatsächlich Ihren Code ausführt. Siehe den folgenden Auszug aus der environment variable wikipedia.

In allen Unix- und Unix-ähnlichen Systemen hat jeder Prozess seine eigenen separaten Umgebungsvariablen. Wenn ein Prozess erstellt wird, erbt er standardmäßig eine doppelte Umgebung des übergeordneten Prozesses außer expliziter Änderungen, die vom übergeordneten Element beim Erstellen des untergeordneten Prozesses vorgenommen werden. Auf der API-Ebene müssen diese Änderungen zwischen dem Ausführen von fork und exec vorgenommen werden. Alternativ kann ein Benutzer von Befehls-Shells wie bash die Umgebungsvariablen für einen bestimmten Befehlsaufruf ändern, indem er ihn indirekt über env oder unter Verwendung der ENVIRONMENT_VARIABLE=VALUE <command>-Notation aufruft. Alle Unix-Betriebssystem-Varianten, DOS und Windows haben Umgebungsvariablen; Sie verwenden jedoch nicht alle die gleichen Variablennamen. Ein laufendes Programm kann auf die Werte von Umgebungsvariablen für Konfigurationszwecke zugreifen.

Also, wenn Sie Ihren Code auszuführen sind pm2 verwenden, dann wird pm2 tatsächlich die vorherige NODE_ENV Umgebungsvariable zuweisen Ihre Anwendung ausgeführt wird. Es verwendet eine JSON file for options, wo Sie Ihre Umgebungsvariablen mit der Eigenschaft env angeben können.

Kurz gesagt, alle Möglichkeiten, Ihre NODE_ENV einzustellen, sind mehr oder weniger gleichwertig, es läuft nur darauf hinaus, wer Ihren Prozess startet.

Da Umgebungsvariablen für eine Maschine lokal sind (Umgebung), werden sie lokal festgelegt und können nicht von einem Client festgelegt werden.

+0

Also, was du sagst, ist 'pm2' wird alle anderen sechs Flags überschreiben, so dass ich sie genauso gut löschen könnte. OK danke. –

+0

Wie gesagt, es hängt völlig davon ab, welcher Prozess Ihre App tatsächlich ausführt, das ist derjenige, der festlegt, wie die Umgebungsvariablen auf – peteb

+0

eingestellt sind. Ja, ich meinte, wenn ich PM2 benutze. Also, wenn ich es mit Knoten ausgeführt habe, würde '{" scripts ": {" start ":" NODE_ENV = production "}}' gewinnen und wenn ich es mit VS Code ausführen würde, dann '{" configurations ": {" env ": "NODE_ENV": "Entwicklung"}} würde gewinnen, oder? –

Verwandte Themen