Para uso en entornos express.js. ¿Alguna sugerencia?
Para uso en entornos express.js. ¿Alguna sugerencia?
Respuestas:
Antes de ejecutar su aplicación, puede hacerlo en la consola,
export NODE_ENV=production
O si estás en Windows, puedes probar esto:
SET NODE_ENV=production
o puedes ejecutar tu aplicación así:
NODE_ENV=production node app.js
También puede configurarlo en su archivo js:
process.env.NODE_ENV = 'production';
Pero no sugiero hacerlo en su archivo de tiempo de ejecución, ya que no es fácil abrir VIM en su servidor y cambiarlo a producción. Puede crear un archivo config.json en su directorio y cada vez que se ejecuta su aplicación, se lee y establece la configuración.
process.env.NODE_ENV
manera confiable desde la propia aplicación. Mejor configure su variable de entorno correctamente como Daniel enlazó a continuación.
NODE_ENV
explícitamente cada vez que ejecuta la aplicación, como en el segundo ejemplo ( NODE_ENV=production node app.js
). De esa manera, potencialmente se salvará de algunos tirones futuros en el caso de que olvide NODE_ENV
volver a configurar su local development
.
cross-env NODE_ENV=production
Funciona en Windows y Linux / Mac.
NODE_ENV=production forever app.js
debería funcionar.
en package.json:
{
...
"scripts": {
"start": "NODE_ENV=production node ./app"
}
...
}
luego ejecutar en la terminal:
npm start
NODE_ENV=production
en package.json no tiene mucho sentido. Ejecutar npm start
en desarrollo lo ejecutará en producción. Puede escribir su código como si siempre fuera producción, ya que siempre lo ejecuta de esa manera. La razón por la que veo para hacer esto sería forzar a otros módulos (por ejemplo, Express) a ejecutarse en modo de producción. ¿Por qué usar variables de entorno si nunca cambian?
¿Nadie mencionado .env
aquí todavía? Haga un .env
archivo en la raíz de su aplicación require('dotenv').config()
y luego lea los valores. Fácilmente cambiado, fácil de leer, multiplataforma.
"mode": "production"
en el .env
archivo funcionó.
export NODE_ENV=production
Es una mala solución, desaparece después de reiniciar.
si no quiere preocuparse más por esa variable, agréguela a este archivo:
/etc/environment
no use la sintaxis de exportación, solo escriba (en una nueva línea si ya hay contenido):
NODE_ENV=production
Funciona después de reiniciar. Ya no tendrá que volver a ingresar el comando export NODE_ENV = production en ningún lugar y simplemente usar el nodo con cualquier cosa que desee, para siempre, pm2 ...
Para heroku:
heroku config:set NODE_ENV="production"
que en realidad es por defecto
NODE_ENV=production gulp bundle-production-app
para agrupar secuencias de comandos listas para producción, en el servidor NODE_ENV está en el entorno del servidor y en la máquina de desarrollo no está allí. En algunas máquinas es una pesadilla si no está configurado y espera tenerlo configurado siempre . En algunos, espera no tenerlo, por lo que no agrega. De todos modos, al hacer las IU, dejo en claro si está en modo de desarrollo para que nunca tenga una pregunta si está activado o desactivado. Si NODE_ENV es! == producción, es evidente que estás en otro modo, así que no hay pesadilla en absoluto. Todo claro, todo bien.
/etc/environment
y ejecutarlo export NODE_ENV=production
?
Para no tener que preocuparse si está ejecutando sus scripts en Windows, Mac o Linux, instale el paquete cross-env . Entonces puedes usar tus scripts fácilmente, así:
"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"
}
Apoyos masivos para los desarrolladores de este paquete.
npm install --save-dev cross-env
heroku config:set NODE_ENV="production"
NODE_ENV=production
ahora es el valor predeterminado en implementaciones de Heroku node.js.
Para Windows Powershell, use este comando
$env:NODE_ENV="production" ; node app.js
En OSX, recomendaría agregar export NODE_ENV=development
a su ~/.bash_profile
y / o ~/.bashrc
y / o ~/.profile
.
Personalmente agrego esa entrada a mi ~/.bashrc
y luego hago que ~/.bash_profile
~/.profile
importe el contenido de ese archivo, para que sea coherente en todos los entornos.
Después de hacer estas adiciones, asegúrese de reiniciar su terminal para recoger la configuración.
Si estás en windows. Abra su cmd en la carpeta correcta y luego primero
set node_env={your env name here}
pulsa enter, entonces puedes comenzar tu nodo con
node app.js
comenzará con su configuración de env
Para tener múltiples entornos, necesita todas las respuestas antes (parámetro NODE_ENV y exportarlo), pero utilizo un enfoque muy simple sin la necesidad de instalar nada. En su package.json solo ponga un script para cada env que necesite, de esta manera:
...
"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"
}
...
Luego, para iniciar la aplicación en lugar de usar el npm start
uso npm run script-prod
.
En el código puede acceder al entorno actual con process.env.NODE_ENV
.
Voila
Windows CMD -> set NODE_ENV=production
Windows Powershell -> $env:NODE_ENV="production"
MAC -> export NODE_ENV=production
Daniel tiene una respuesta fantástica, que es el mejor enfoque para el proceso correcto de implementación (configurar y olvidar).
Para aquellos que usan express. Puedes usar grunt-express-server, que también es fantástico. https://www.npmjs.org/package/grunt-express-server
Puede ser una posibilidad que haya realizado dos instancias de secuenciar objetos
por ejemplo: var con1 = new Sequelize (); var con2 = new Sequelize ();
que también ocurrirá el mismo error