Dans Ubuntu, c'est assez simple; Je peux exécuter l'application en utilisant:
$ NODE_ENV=production node myapp/app.js
Cependant, cela ne fonctionne pas sous Windows. Existe-t-il un fichier de configuration où je peux définir l'attribut?
Dans Ubuntu, c'est assez simple; Je peux exécuter l'application en utilisant:
$ NODE_ENV=production node myapp/app.js
Cependant, cela ne fonctionne pas sous Windows. Existe-t-il un fichier de configuration où je peux définir l'attribut?
Réponses:
Les versions actuelles de Windows utilisent Powershell comme shell par défaut, utilisez donc:
$env:NODE_ENV="production"
Selon la réponse de @ jsalonen ci-dessous. Si vous êtes en CMD (qui n'est plus maintenu), utilisez
set NODE_ENV=production
Cela doit être exécuté dans l'invite de commande où vous avez l'intention d'exécuter votre application Node.js.
La ligne ci-dessus définirait la variable d'environnement NODE_ENV pour l'invite de commande où vous exécutez la commande.
Pour définir les variables d'environnement globalement afin qu'elles persistent au-delà de la seule invite de commande, vous pouvez trouver l'outil dans Système dans le Panneau de configuration (ou en tapant «environnement» dans la zone de recherche du menu Démarrer).
set NODE_ENV=production && node app
. Plus facilement configurer votre package.json
conséquence: "scripts": { "start": "set NODE_ENV=production && node app" }
.
echo %NODE_ENV%
pour vérifier sa valeur actuelle.
cross-env
est la meilleure solution à ce problème si votre équipe travaille sur des systèmes d'exploitation mixtes. La réponse de @MoOx serait mon choix comme réponse à cette question.
Je viens de trouver un joli package Node.js qui peut beaucoup aider à définir des variables d'environnement à l'aide d'une syntaxe unique, multiplateforme.
https://www.npmjs.com/package/cross-env
Cela vous permet d'écrire quelque chose comme ceci:
cross-env NODE_ENV=production my-command
Ce qui est assez pratique! Plus de commandes spécifiques Windows ou Unix!
Dans PowerShell:
$env:NODE_ENV="production"
set NODE_ENV=production
n'a pas fonctionné pour moi en PowerShell mais cela a fonctionné. Merci!
$env:NODE_ENV="development"; gulp runMytask
. Notez le point-virgule là-dedans. Le fichier gulp peut utiliser une logique conditionnelle sur process.env.NODE_ENV. À moins que vous ne le définissiez, il ne sera pas défini.
cross-env NODE_ENV=production
option est vraiment une meilleure solution si vous exécutez des commandes npm à partir de package.json qui nécessitent la définition de l'env. Il est trop facile de laisser l'ensemble env sur dev / prod après avoir utilisé le $ env: Option NODE_ENV
Il serait idéal si vous pouviez définir des paramètres sur la même ligne que votre appel pour démarrer Node.js sous Windows. Examinez attentivement ce qui suit et exécutez-le exactement comme indiqué:
Vous avez ces deux options:
Sur la ligne de commande:
set NODE_ENV=production&&npm start
ou
set NODE_ENV=production&&node index.js
L'astuce pour que cela fonctionne sous Windows est que vous devez supprimer les espaces avant et après le "&&". Configuré votre fichier package.json avec start_windows (voir ci-dessous) ci-dessous. Exécutez ensuite "npm run start_windows" sur la ligne de commande.
//package.json
"scripts": {
"start": "node index.js"
"start_windows": "set NODE_ENV=production&&node index.js"
}
Vous pouvez utiliser
npm run env NODE_ENV=production
C'est probablement la meilleure façon de le faire, car il est compatible à la fois avec Windows et Unix.
Dans la documentation du script d'exécution npm :
Le script env est une commande intégrée spéciale qui peut être utilisée pour répertorier les variables d'environnement qui seront disponibles pour le script au moment de l'exécution. Si une commande "env" est définie dans votre package, elle aura priorité sur la commande intégrée.
npm run env NODE_ENV=production -- node -e 'console.log(process.env.NODE_ENV)'
Le --
est obligatoire . Remplacez node -e 'console.log(process.env.NODE_ENV)'
par la commande que vous souhaitez.
npm run env NODE_TLS_REJECT_UNAUTHORIZED=0 -- node --inspect ./etc/http-req-standalone.js
et ... rien ne s'est passé. Je ne suis pas sûr que cette méthode fonctionne sur Windows.
Si vous utilisez Visual Studio avec NTVS, vous pouvez définir les variables d'environnement sur la page des propriétés du projet:
Comme vous pouvez le voir, les listes déroulantes Configuration et Plateforme sont désactivées (je n'ai pas trop cherché à comprendre pourquoi), mais si vous modifiez votre .njsproj
fichier comme suit:
<PropertyGroup Condition=" '$(Configuration)' == 'Debug' ">
<DebugSymbols>true</DebugSymbols>
<Environment>NODE_ENV=development</Environment>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)' == 'Release' ">
<DebugSymbols>true</DebugSymbols>
<Environment>NODE_ENV=production</Environment>
</PropertyGroup>
La liste déroulante 'Debug / Release' contrôlera ensuite la façon dont la variable est définie avant de démarrer Node.js.
J'ai écrit un module win-node-env avec lequel vous pouvez exécuter votre commande comme vous le feriez dans * nix.
NODE_ENV=production node myapp/app.js
Cela fonctionne en créant un NODE_ENV.cmd
qui définit laNODE_ENV
variable d'environnement et génère un processus enfant avec le reste de la commande et ses arguments.
Il suffit de l'installer (globalement) et d'exécuter vos commandes de script npm, cela devrait automatiquement les faire fonctionner.
npm install -g win-node-env
Mon expérience avec Node.js sur Windows 7 64 bits dans Visual Studio 2013 est que vous devez utiliser
setx NODE_ENV development
à partir d'une fenêtre cmd. ET vous devez redémarrer Visual Studio pour que la nouvelle valeur soit reconnue.
La syntaxe définie ne dure que pour la durée de la fenêtre cmd dans laquelle elle est définie.
Test simple dans Node.js:
console.log('process.env.NODE_ENV = ' + process.env.NODE_ENV);
Il renvoie «non défini» lors de l'utilisation de set, et il retournera «développement» si vous utilisez setx et redémarrez Visual Studio.
cmd
- pas PowerShell? Ugh, viens aux fenêtres, rassemble-le.
Voici la méthode sans ligne de commande:
Sous Windows 7 ou 10, saisissez environnement dans la zone de recherche du menu Démarrer, puis sélectionnez Modifier les variables d'environnement système.
Sinon, accédez à Panneau de configuration \ Système et sécurité \ Système, puis cliquez sur Paramètres système avancés
Cela devrait ouvrir la boîte de dialogue Propriétés système avec l'onglet Avancé sélectionné. En bas, vous verrez un bouton Variables d'environnement .... Cliquez ici.
La boîte de dialogue Variables d'environnement s'ouvre.
En bas, sous Variables système, sélectionnez Nouveau ... Cela ouvrira la boîte de dialogue Nouvelle variable système.
Saisissez le nom et la valeur de la variable, puis cliquez sur OK.
Vous devrez fermer toutes les invites cmd et redémarrer votre serveur pour que la nouvelle variable soit disponible pour process.env. S'il ne s'affiche toujours pas, redémarrez votre ordinateur.
Juste pour clarifier, et pour toute autre personne qui pourrait se tirer les cheveux ...
Si vous utilisez git bash sous Windows , set node_env=production&& node whatever.js
cela ne semble pas fonctionner . Utilisez plutôt la cmd native. Ensuite, en utilisantset node_env=production&& node whatever.js
travaux comme prévu.
Mon cas d'utilisation:
Je développe sur Windows car mon flux de travail est beaucoup plus rapide, mais je devais m'assurer que le middleware spécifique au développement de mon application ne se déclenchait pas dans l'environnement de production.
Pour exécuter votre application dans PowerShell (depuis &&
n'est pas autorisé):
($env:NODE_ENV="production") -and (node myapp/app.js)
Notez que la sortie texte de ce que fait le serveur est supprimée, et je ne suis pas sûr que ce soit réparable. (Développant la réponse de @ jsalonen.)
"debug-windows": "($env:NODE_ENV=\"dev\") -and (node src/dequeue.js)"
Pour plusieurs variables d'environnement, un .env
fichier est plus pratique:
# .env.example, committed to repo
DB_HOST=localhost
DB_USER=root
DB_PASS=s1mpl3
# .env, private, .gitignore it
DB_HOST=real-hostname.example.com
DB_USER=real-user-name
DB_PASS=REAL_PASSWORD
Il est facile à utiliser avec dotenv-safe
:
npm install --save dotenv-safe
.index.js
) et utilisez-le directement avec la process.env
commande :require('dotenv').load()
console.log(process.env.DB_HOST)
N'oubliez pas d' ignorer le .env
fichier dans votre VCS .
Votre programme échoue alors rapidement si une variable "définie" dans .env.example
n'est pas définie en tant que variable d'environnement ou dans .env
.
Dans le cas où vous utilisez le terminal GITBASH
"set NODE_ENV=production"
ne fonctionnera pas, que pouvez-vous faire est de taper "exportNODE_ENV=production"
cela ne définira pas de variable mais c'est utile dans de nombreux cas. Je ne recommanderai pas d'utiliser cela pour la production, mais ça devrait aller si vous jouez avec npm.
npm install --production
J'ai utilisé le script npm pour exécuter une tâche gulp sans "&&"
NODE_ENV = testcases npm run seed-db
Redémarrez le code VS si le NODE_ENV ou toute autre variable d'environnement ne fournit pas la valeur correcte. Cela devrait fonctionner après le redémarrage.