Comment configurer NODE_ENV en production / développement sous OS X


Réponses:


664

Avant d'exécuter votre application, vous pouvez le faire dans la console,

export NODE_ENV=production

Ou si vous êtes dans Windows, vous pouvez essayer ceci:

SET NODE_ENV=production

ou vous pouvez exécuter votre application comme ceci:

NODE_ENV=production node app.js

Vous pouvez également le définir dans votre fichier js:

process.env.NODE_ENV = 'production';

Mais je ne suggère pas de le faire dans votre fichier d'exécution, car il n'est pas facile d'ouvrir VIM sur votre serveur et de le changer en production. Vous pouvez créer un fichier config.json dans votre répertoire et chaque fois que votre application s'exécute, elle le lit et définit la configuration.


12
C'est un mauvais conseil. Ça va être un réglage difficile de process.env.NODE_ENVmanière fiable à partir de l'application elle-même. Il est préférable de définir correctement votre variable d'environnement comme Daniel le relie ci-dessous.
MK Safi

15
Je suis un fan de la définition NODE_ENVexplicite à chaque fois que vous exécutez l'application, comme dans le deuxième exemple ( NODE_ENV=production node app.js). De cette façon, vous vous épargnerez peut-être de quelques épilations futures dans le cas où vous oublieriez de NODE_ENVremettre votre local à development.
Jon

Pas si brillant du tout. Chaque fois que vous exécutez votre application, vous devez ajouter cette variable env. Ça craint. Publié une meilleure solution ci-dessous.
Lukas Liesis

2
Reportez-vous à npmjs.com/package/cross-env pour une solution multiplateforme simple. cross-env NODE_ENV=productionfonctionne sur windows et linux / mac.
AntonB

1
@Gleb NODE_ENV=production forever app.jsdevrait fonctionner.
Farid Nouri Neshat

102

dans package.json:

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

puis lancez dans le terminal:

npm start

1
ne commencez pas à mettre un tas de scripts dans package.json, c'est une mauvaise pratique car vous introduisez des incohérences et cela tue l'immuabilité dans vos projets. Je sais que beaucoup de gens créent des scripts pour exécuter grunt ou gulp mais ne le font pas
PositiveGuy

38
@WeDoTDD de quoi parlez-vous? Ces scripts sont destinés à être utilisés de la même manière que le fonctionnement du makefile. L'utiliser comme cet exemple ou comme vous l'avez mentionné pour exécuter gulp est un cas d'utilisation parfaitement raisonnable. Pour les tâches simples, je n'utilise même plus gulp et je fais tout à l'intérieur du script, il est beaucoup plus rapide de faire fonctionner les choses et je laisse webpack faire le travail qui était auparavant effectué par gulp.
Marko Grešak

15
@WTF - Que voulez-vous dire par "mauvaise pratique" d'utiliser des scripts dans package.json? C'est le sens de la section scripts: mettre des scripts! Son parfaitement valide et élimine le besoin de gorgée ou de grognement. Tout se fait via la commande et le webpack.
TetraDev

6
@WTF L'utilisation de scripts améliore considérablement la cohérence. Vous pouvez configurer un ensemble standard de commandes à utiliser sur plusieurs projets qui ne peuvent pas utiliser les mêmes scripts de construction, bibliothèques, etc. sous-jacents. Vous pouvez au moins essayer de vous appuyer sur des faits et des exemples.
Lewis Diamond

4
Mettre NODE_ENV=productiondans package.json n'a pas beaucoup de sens. L'exécution npm starten cours de développement l'exécutera en production. Vous pourriez aussi bien écrire votre code que s'il est toujours en production, puisque vous l'exécutez toujours de cette façon. La seule raison pour laquelle je vois cela serait de forcer d'autres modules (par exemple Express) à fonctionner en mode production. Pourquoi utiliser des variables d'environnement du tout si elles ne changent jamais?
Nateowami

65

Personne encore mentionné .envici? Créez un .envfichier dans la racine de votre application, puis require('dotenv').config()lisez les valeurs. Facilement changé, facilement lu, multiplateforme.

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


1
Bizarre, personne ne le mentionne, la meilleure solution à mon avis. Mettez le nom de l'environnement dans le même fichier avec le reste des variables.
Asinus Rex

2
La définition de NODE_ENV dans le fichier .env ne fonctionnera pas. Voir ceci: github.com/motdotla/dotenv/issues/328
Michael Zelensky

Pour moi, la mise "mode": "production"dans le .envfichier a fonctionné.
DarkLite1

46

export NODE_ENV=production est une mauvaise solution, elle disparaît après redémarrage.

si vous ne voulez plus vous soucier de cette variable - ajoutez-la à ce fichier:

/etc/environment

n'utilisez pas la syntaxe d'exportation, écrivez simplement (dans une nouvelle ligne si du contenu est déjà là):

NODE_ENV=production

cela fonctionne après le redémarrage. Vous n'aurez plus à ressaisir la commande d' exportation NODE_ENV = production n'importe où et à utiliser simplement le nœud avec tout ce que vous souhaitez - pour toujours, pm2 ...

Pour heroku:

heroku config:set NODE_ENV="production"

qui est en fait par défaut.


2
Cauchemar d'entretien. Qu'en est-il d'une boîte où vous n'avez pas les autorisations pour / etc?
Thomas McCabe

1
NODE_ENV=production gulp bundle-production-appPersonnellement, j'utilise pour regrouper le script prêt à la production, dans le serveur NODE_ENV est dans l'environnement du serveur et dans la machine de développement, il n'est pas là. Dans certaines machines, c'est un cauchemar si ce n'est pas réglé et vous vous attendez à ce qu'il soit toujours réglé . Dans certains, vous vous attendez à ne pas l'avoir, donc vous n'ajoutez pas. Quoi qu'il en soit, tout en faisant des interfaces utilisateur, je précise qu'il est en mode développement, vous n'avez donc jamais de question s'il est activé ou désactivé. Si NODE_ENV est! == production c'est dans votre visage que vous êtes dans un autre mode, donc pas de cauchemar du tout. Tout est clair, tout va bien.
Lukas Liesis

+1 pour avoir expliqué comment le faire persister. Je me demande combien de personnes l'ont défini uniquement dans la session en cours en pensant qu'il persistera. Et avant un redémarrage? Si vous voulez le régler tout de suite, devez-vous le mettre en place /etc/environment et courir export NODE_ENV=production?
Nateowami

24

Pour ne pas avoir à vous soucier si vous exécutez vos scripts sur Windows, Mac ou Linux, installez le package cross-env . Ensuite, vous pouvez facilement utiliser vos scripts, comme ceci:

"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"
}

Accessoires massifs aux développeurs de ce package.

npm install --save-dev cross-env

22
heroku config:set NODE_ENV="production"

2
ahhh c'est ce dont j'avais besoin. tu es génial
Connor Leech

5
NODE_ENV=productionest désormais la valeur par défaut dans Heroku node.js deploys.
sean

1
Heroku n'est pas le seul endroit à déployer
Pavan Katepalli

9

Pour Windows Powershell, utilisez cette commande

$env:NODE_ENV="production" ; node app.js

6

Sur OSX, je recommanderais d'ajouter export NODE_ENV=developmentà votre ~/.bash_profileet / ou ~/.bashrcet / ou ~/.profile.

Personnellement, j'ajoute cette entrée à mon ~/.bashrc, puis ~/.bash_profile ~/.profilej'importe le contenu de ce fichier, afin qu'il soit cohérent dans tous les environnements.

Après avoir effectué ces ajouts, assurez-vous de redémarrer votre terminal pour récupérer les paramètres.


2

Si vous êtes sous Windows. Ouvrez votre cmd dans le bon dossier puis d'abord

set node_env={your env name here}

appuyez sur Entrée, vous pouvez démarrer votre nœud avec

node app.js

cela commencera par votre réglage env


1
ne disparaîtra-t-il pas après redémarrage? Je n'ai pas de fenêtres, je ne peux pas m'essayer.
Lukas Liesis

Si vous demandez le redémarrage du nœud non, il ne disparaîtra pas tant que vous n'aurez pas complètement fermé l'invite de commande. Mais si Windows Server redémarre, il disparaîtra.
garenyondem

2
parler de redémarrage du système d'exploitation. C'est pourquoi je ferais mieux de trouver une autre façon de cesser de me demander à chaque fois que les mises à jour de Windows sont installées, ou tout simplement de redémarrer, à propos de ce problème encore et encore.
Lukas Liesis

2

Si vous utilisez webpack dans votre application, vous pouvez simplement le configurer là-bas, en utilisant DefinePlugin...

Donc, dans votre pluginsection, définissez NODE_ENV sur production:

plugins: [
  new webpack.DefinePlugin({
    'process.env.NODE_ENV': '"production"',
  })
]

1

Afin d'avoir plusieurs environnements, vous avez besoin de toutes les réponses avant (paramètre NODE_ENV et l'exporter), mais j'utilise une approche très simple sans avoir besoin d'installer quoi que ce soit. Dans votre package.json, mettez simplement un script pour chaque env dont vous avez besoin, comme ceci:

...
"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"
  }
 ...

Ensuite, pour démarrer l'application au lieu d'utiliser npm startuse npm run script-prod.

Dans le code, vous pouvez accéder à l'environnement actuel avec process.env.NODE_ENV.

Voila.


NODE_ENV devrait être "développement" ou "production", ce qui précède n'est pas reconnu par le code tiers (bien que vous puissiez consulter process.env pour cela)
John Culviner

1

CMD Windows -> set NODE_ENV=production

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

MAC -> export NODE_ENV=production



0

Il se peut que vous ayez créé deux instances d'objet séquentiel

par exemple: var con1 = new Sequelize (); var con2 = new Sequelize ();

que la même erreur se produira également

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.