Pour une utilisation dans des environnements express.js. Aucune suggestion?
Pour une utilisation dans des environnements express.js. Aucune suggestion?
Réponses:
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.
process.env.NODE_ENV
maniè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.
NODE_ENV
explicite à 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_ENV
remettre votre local à development
.
cross-env NODE_ENV=production
fonctionne sur windows et linux / mac.
NODE_ENV=production forever app.js
devrait fonctionner.
dans package.json:
{
...
"scripts": {
"start": "NODE_ENV=production node ./app"
}
...
}
puis lancez dans le terminal:
npm start
NODE_ENV=production
dans package.json n'a pas beaucoup de sens. L'exécution npm start
en 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?
Personne encore mentionné .env
ici? Créez un .env
fichier dans la racine de votre application, puis require('dotenv').config()
lisez les valeurs. Facilement changé, facilement lu, multiplateforme.
"mode": "production"
dans le .env
fichier a fonctionné.
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.
NODE_ENV=production gulp bundle-production-app
Personnellement, 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.
/etc/environment
et courir export NODE_ENV=production
?
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
heroku config:set NODE_ENV="production"
NODE_ENV=production
est désormais la valeur par défaut dans Heroku node.js deploys.
Pour Windows Powershell, utilisez cette commande
$env:NODE_ENV="production" ; node app.js
Sur OSX, je recommanderais d'ajouter export NODE_ENV=development
à votre ~/.bash_profile
et / ou ~/.bashrc
et / ou ~/.profile
.
Personnellement, j'ajoute cette entrée à mon ~/.bashrc
, puis ~/.bash_profile
~/.profile
j'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.
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
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 start
use npm run script-prod
.
Dans le code, vous pouvez accéder à l'environnement actuel avec process.env.NODE_ENV
.
Voila.
CMD Windows -> set NODE_ENV=production
Windows PowerShell -> $env:NODE_ENV="production"
MAC -> export NODE_ENV=production
Daniel a une réponse fantastique qui est la meilleure approche pour le processus de déploiement correct (définir et oublier).
Pour ceux qui utilisent express. Vous pouvez également utiliser grunt-express-server, ce qui est fantastique. https://www.npmjs.org/package/grunt-express-server
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