Related
My NX application's npm run build:server calls ng build api-server that triggers the #nrwl/node:build builder.
It builds the NestJS application as main.js. Things work except I wanted process.env.NODE_ENV to be evaluated at runtime but I think it was resolved at build time (via Webpack).
Currently, the value is always set to 'development'.
I am new to Nrwl's NX. Any solution this?
In NestJs/Nodejs app in Nx.Dev workspace process.env.NODE_ENV is replaced during compilation from typescript to javascript very "smart way" to "development" string constant (everything like NODE_ENV is replaced). I don't know why. But only way how can I get real NODE_ENV in runtime is this code:
//process.env.NODE_ENV
process.env['NODE' + '_ENV']
The reason you're seeing development is because you're building the app in development mode - it's not best practice to evaluate at runtime because then the builder can't do fancy things to make the build production ready. If you want production, you need to build the app in production mode by adding the --prod flag (just like how you need to build Angular in production mode).
If you need to serve the app in production mode (instead of build) the default config doesn't provide you with a prod mode for serve. You'll need to add the configuration to your angular.json.
So this code:
"serve": {
"builder": "#nrwl/node:execute",
"options": {
"buildTarget": "api-server:build"
}
},
Would become
"serve": {
"builder": "#nrwl/node:execute",
"options": {
"buildTarget": "api-server:build"
},
"configurations": {
"production": {
"buildTarget": "api-server:build:production"
}
}
},
and then you can run
ng serve --project=api-server --prod
Indeed the nx builder will replace the expression process.env.NODE_ENV in our source code with the current value of the env var (or the nx-mode).
What happens is this:
the build command executes the nx builder which creates a configuration for web-pack
this configuration instructions for the webpack-define plugin to replace the text process.env.NODE_ENV during compilation with the actual value of the env-var (or the nx-mode):
see nx-code getClientEnvironment()
Since the webpack-define plugin will look for the text process.env.NODE_ENV, it's easy to use a workaround as explained in this answer:
process.env['NODE'+'_ENV']
Warning
When you need to apply this workaround to make your app work, then something is wrong. Since you have compiled your app in production mode, it does not make sense to pass another value for NODE_ENV when you start the (production) app.
The webpack Production page contains some helpful info.
We also had this case, and the issue was, that we relied on the NODE_ENV variable to load different database configs for dev, prod, test, etc.
The solution for our case was to simply use separate env-vars for the database config (e.g. DB_NAME, DB_PORT, ..), so that we can use different db-configs at runtime with any build-variants: dev, prod, test, etc.
I recently faced the same problem using Express instead of Nest.
What we did to overcome this was adding some file replacements when compiling for any of our environments (development, production, staging, staging-dev). This is done in the angular.json file the same way the environment files are replaced for the Angular app .
Another approach that worked for us, was loading the environment variables only once, and retrieve them from that origin. As our app relies on Express for it's backend the used the Express env variable as:
import express from 'express';
const _app = express();
const _env = _app.get('env');
console.log(_env); // shows the right environment value set on NODE_ENV
To come to this conclusion we checked Express code for the env variable and it does use process.env.NODE_ENV internally.
Hope it helps. Best regards.
We had the same issue, we eventually used the cross-env package in our package.json:
"prodBuild": "cross-env NODE_ENV=production nx run api-server:build:production",
"prodServe": "cross-env NODE_ENV=production nx run api-server:serve:production"
process.env is indeed only available at run-time. What is probably happening is that you are not setting this value when running your application. Can I ask how you are running it?
As a trivial example
# The following will read the environment variables that are defined in your shell (run `printenv` to see what those are)
> node main.js
# this will have your variable set
> NODE_ENV=production node main.js
Of course you want to have it actually set in your environment when deploying the app rather then passing it in this way, but if you're doing it locally you can do it like this.
I am a java script full stack developer.
In the vue js I create two files in the root.
env.development
env.production
In my main.js file, I can access environment variables like this
process.env.VUE_APP_MY_VARIABLE_X
How production and development differs in the vue js is,
if I use npm run serve project loaded the development environment variables. If I use npm run build it takes production environment variables. That's all in vue.
But in my expressjs project,
"start": "nodemon server.js --exec babel-node -e js",
This command will always responsible for the run project. I couldn't find two commands like in vue. I go though the tutorials every body says use the package called dotenv.
I couldn't figure out that how could this package identify the environments this is production and this is development.
End of the day I want to set my db password to 123456 in my local machine and root#123456 in the server. How could I achieve this?
Vue.js handles modes automatically, depending on the command (e.g. serve sets NODE_ENV=development, while build sets NODE_ENV=production).
Depending on the mode, it also automatically loads files with variables from disk.
Environment variables in Node.JS
However, Node.JS does not do that by default, and you have to set up your application to handle environment variables.
In Node.JS you can pass variables via the shell command, for example:
MY_VARIABLE=x node myapp.js (by prepending the command with variables), and that will give you process.env.MY_VARIABLE inside your myapp.js application.
Following this behavior, there's a consensus on using NODE_ENV variable for setting up the environment mode.
For production use, you'd start your application using NODE_ENV=production node myapp.js, while for development NODE_ENV=development node myapp.js.
Of course, if your machine already has these environment variables set up (for instance in .bash_profile) you do not need to prepend your command with them.
As a practice, in development machines, you'd have these variables already set up on your machine, while production machines (e.g. docker containers, etc) start clean and you pass the environment variables when starting your application.
For example, Heroku (and other deployment services) allow you to set up environment variables which are set at machine start.
There's also the method of storing variables in files (such as the .env, or other files), but those you'd have to read from disk when your application starts.
And this is where dotenv (and config package) come in play.
What dotenv does, is it reads .env file stored in your application execution path (root of the app), and sets any variables defined there into process.env for Node.JS to use.
This is extremely useful for development machines, but on production it's recommended to not have files that store sensitive information in variables, but rather use system environment variables.
There is also the option, for production machines, to construct or load into the machine an .env file at machine setup time, into the app directory.
Note:
never commit .env or config files that store passwords and sensitive information, to your repository
never store development and production variables in the same file
The dotenv approach
The best way to go about it, would be to use dotenv, and have different .env files, one on your development machine, and a different one on your production machine. That way, when your application starts, it reads the variables that are stored in the adjacent .env. This is the most secure and reliable way, in absence of means to pass environment variables to your production machine from a machine management application/interface.
The easiest way to set up your app with dotenv would be to set your start command to something like:
"start": "nodemon --exec \"node -r dotenv/config\" server.js"
and then in the .env file stored on your local/development machine you'd have something similar to:
DATABASE_PASSWORD=1235
DATABASE_USERNAME=joe-dev
...
and in the .env file on your production machine (server):
DATABASE_PASSWORD=root#1235
DATABASE_USERNAME=root
...
according to my understanding
you don't have created and setup a config file and required it in your app.js or any other file. let see for example create config file
const config = {
"development":{
"host":"localhost",
"dbport":"27017",
"port":"",
"username":"",
"password":"",
"userdb":"",
"passworddb":"123456",
"authSource":"",
"database":"devDB"
},
"staging":{
"host":"",
"dbport":"",
"port":"",
"username":"",
"password":"",
"passworddb":"#123456",
"database":"stageDB",
},
"production":{
"host":"",
"dbport":"",
"port":"",
"userdb":"",
"passworddb":"#123456",
"username":"",
"password":"",
"database":"prodDB",
}
};
module.exports = config;
then you have you setup a variable in your .env file like NodeENV = 'prod'
then import it into your files like
var config = require('./config')["process.env.NodeENV"];
and one more last thing dotenv is only used to loads environment variables from a .env file into process.env.
I am running config#1.30.0 and I am attempting to get settings from the environment variables using .\config\custom-environment-variables.json does not work. However, it reads from the .\config\default.json just fine.
.\config\custom-environment-variables.json
{
"key": "app_key"
}
.\config\default.json
{
"key": "defaultKey"
}
running
const config = require('config');
console.log(config.get('key'))
always prints
defaultKey
but prints nothing when I set the key property in config/default to an empty string. How can I resolve this?
What I have tried
Opened a new console anytime I set the environment variable using set app_key=newKey
Set the environment manually
The config file name relates to the NODE_ENV environment variable you use when starting node.
The purpose of the module is to have a config file for each type of environment you are deploying to test, staging, prod environments. Default takes over if nothing is set or a file can't be find
e.g. for test and staging environments you would have.
config/default.json
{
"key": "default_key"
}
config/test.json
{
"key": "test_key"
}
config/production.json
{
"key": "prod_key"
}
app.js
var config = require('config')
console.log(config.key)
Then if you run with a different NODE_ENV the same name as the file in the config directory you get the different keys
node app.js // output default_key
NODE_ENV=test node app.js // output test_key
NODE_ENV=production node app.js // output prod_key
You question references custom environment variables using the file config/custom-environment-variables.json This file will enable you to override a value in one of the files with a environment variable set when running node. This is useful when you can't commit the variable, such as database key but might want to access all your config in the same place.
e.g.
{
"key": "SECURE_DATABASE_KEY"
}
Then running the same program again with the new config file:
NODE_ENV=production node app.js // output prod_key
SECURE_DATABASE_KEY=asldfj40 NODE_ENV=production node app.js // output asldfj40
I ran into a similar problem and found that if I don't open a new terminal window and I restart the server in the same window where I run export some_secret=immasecret, then the app doesn't crash and the some_secret variable can be accessed. I'd previously been trying to access the variable while running node in another window.
This issue is with VSCODE Editors Integrated Terminal
We have also struggled a lot with this issue initially, but the issue is that you might be using the integrated terminal that comes with VSCODE there is an issue with that, please try to use some external terminals like cmder or cmd prompt that comes with windows you will get the output as you are expecting.
USE EXTERNAL TERMINAL OR CMD PROMPT to execute the code
A solution is custom-env nodejs module, it allows you to add different environment variables for different stages using the popular .env method. Example .env for dev environment and .env.staging for staging environment
Your files and codes are correct your cmd command is wrong
use this command
setx app_key NewKey
Attention!
If config/production.json
{
"key": "prod_key"
}
and config/local.json
{
"key": "local_key"
}
and
NODE_ENV=production node app.js
the Output is: local_key
If a local.json exist is NODE_ENV=production is ignored
Details s. config Wiki (it is very refined, unfortunately too few examples)
When I'm in dev mode I don't want my server to send email and some other stuff so I have this in server.js file:
process.env.NODE_ENV = 'development';
When I move it to production i change the value to 'production'.
Problem is of course that it is easy to forget on deployments. Is it possible somehow to detect when server is in production?
If it's not, is it possible to write a batch script that replaces a string in a file?
You shouldn't manually change values of process.env object, because this object is reflecting your execution environment.
In your code you should do the following:
const environment = process.env.NODE_ENV || 'development';
And then you launch your app in production like this:
$ NODE_ENV=production node app.js
If NODE_ENV environment variable is not set, then it will be set to development by default.
You could also use dotenv module in development to specify all environment variables in a file.
Furthermore, I've implemented a reusable module, which allows to automatically detect environment by analyzing both CLI arguments and NODE_ENV variable. This could be useful on your development machine, because you can easily change environment by passing a CLI argument to you Node.js program like this: $ node app.js --prod. It's also nice to use with Gulp: $ gulp build --prod.
Please see more details and use cases on the detect-environment's page.
The suggested way to tackle these kind of problems is by using the process global object provided by NodeJS. For example:
var env = process.env.NODE_ENV || "development";
By the above line. We can easily switch between development / production environment. If we haven't configured any environment variable it works with development environment.
process.env is an object that contains the user environment.
For example if we are running our application in a bash shell and have configured NODE_ENV to production. Then i can access that in node application as process.env.NODE_ENV.
There are multiple ways to define this NODE_ENV variable for nodejs applications:
## Setting environment variable for bash shell
export NODE_ENV=production
## Defined while starting the application
NODE_ENV=production node app.js
So i don't think you would require any batch file for this. When handling multiple configuration variables, follow this.
This is normally handled through configuration files (e.g. config frameworks like node-convict) and through environmental variables. In the start command in production, you might do something like:
NODE_ENV=production npm start
then the process.env.NODE_ENV would be properly set by any module in your app that cares.
I'm trying to follow a tutorial and it says:
There are a few ways to load credentials.
Loaded from environment variables,
Loaded from a JSON file on disk,
The keys need to be as follows:
USER_ID, USER_KEY
...This means that if you properly set your environment variables, you
do not need to manage credentials in your application at all.
Based on some Googling, it appears that I need to set the variables in process.env? How and where do I set these credentials? Example Please.
Environment variables (in this case) are being used to pass credentials to your application. USER_ID and USER_KEY can both be accessed from process.env.USER_ID and process.env.USER_KEY respectively. You don't need to edit them, just access their contents.
It looks like they are simply giving you the choice between loading your USER_ID and USER_KEY from either process.env or some specificed file on disk.
Now, the magic happens when you run the application.
USER_ID=239482 USER_KEY=foobar node app.js
That will pass the user id 239482 and the user key as foobar. This is suitable for testing, however for production, you will probably be configuring some bash scripts to export variables.
I highly recommend looking into the dotenv package.
https://github.com/motdotla/dotenv
It's kind of similar to the library suggested within the answer from #Benxamin, but it's a lot cleaner and doesn't require any bash scripts. Also worth noting that the code base is popular and well maintained.
Basically you need a .env file (which I highly recommend be ignored from your git/mercurial/etc):
FOO=bar
BAZ=bob
Then in your application entry file put the following line in as early as possible:
require('dotenv').config();
Boom. Done. 'process.env' will now contain the variables above:
console.log(process.env.FOO);
// bar
The '.env' file isn't required so you don't need to worry about your app falling over in it's absence.
You can set the environment variable through process global variable as follows:
process.env['NODE_ENV'] = 'production';
Works in all platforms.
Just provide the env values on command line
USER_ID='abc' USER_KEY='def' node app.js
If you want a management option, try the envs npm package. It returns environment values if they are set. Otherwise, you can specify a default value that is stored in a global defaults object variable if it is not in your environment.
Using .env ("dot ee-en-vee") or environment files is good for many reasons. Individuals may manage their own configs. You can deploy different environments (dev, stage, prod) to cloud services with their own environment settings. And you can set sensible defaults.
Inside your .env file each line is an entry, like this example:
NODE_ENV=development
API_URL=http://api.domain.com
TRANSLATION_API_URL=/translations/
GA_UA=987654321-0
NEW_RELIC_KEY=hi-mom
SOME_TOKEN=asdfasdfasdf
SOME_OTHER_TOKEN=zxcvzxcvzxcv
You should not include the .env in your version control repository (add it to your .gitignore file).
To get variables from the .env file into your environment, you can use a bash script to do the equivalent of export NODE_ENV=development right before you start your application.
#!/bin/bash
while read line; do export "$line";
done <source .env
Then this goes in your application javascript:
var envs = require('envs');
// If NODE_ENV is not set,
// then this application will assume it's prod by default.
app.set('environment', envs('NODE_ENV', 'production'));
// Usage examples:
app.set('ga_account', envs('GA_UA'));
app.set('nr_browser_key', envs('NEW_RELIC_BROWSER_KEY'));
app.set('other', envs('SOME_OTHER_TOKEN));
It depends on your operating system and your shell
On linux with the shell bash, you create environment variables like this(in the console):
export FOO=bar
For more information on environment variables on ubuntu (for example):
Environment variables on ubuntu
Windows-users: beware! These commands are recommended for Unix. But on Windows they don't persist, they only set a variable in your current shell, and it'll be gone when you restart.
SET TEST="hello world"
$env:TEST = "hello world"
3 ways to set a persistent environment variable on Windows:
A) .env file in your project - The best method. As you can just copy that file to any computer and get the same config when running the project.
Create an .env file in your project folder root with the content: TEST="hello world"
Write some node code that will read that file. I suggest installing dotenv ( npm install dotenv --save) and then add require('dotenv').config(); during your node setup code.
process.env.TEST is now usable in node
Env-files are a good way of keeping api-keys out of your codebase
B) Use Powershell - this will create a variable that will be accessible in other terminals. But it sucks as it'll be lost after you restart your computer.
[Environment]::SetEnvironmentVariable("TEST", "hello world", "User")
This method is widely recommended on Windows forums, people seem unaware it doesn't persist after a system restart....
C) Use the Windows GUI
Search for "Environment Variables" in the Start Menu Search or in the Control Panel, Select "Edit the system environment variables". A dialogue opens and you click the button "Environment Variables" at the bottom of the dialogue to open an edit-view where you can click the "New" button to add a new environment variable. Easy. And persists even after a restart. But not something you should use to config a specific codebase.
Like ctrlplusb said, I recommend you to use the package dotenv, but another way to do this is creating a js file and requiring it on the first line of your app server.
env.js:
process.env.VAR1="foo"
process.env.VAR2="bar"
app.js:
require('./env') // env.js relative path.
console.log(process.env.VAR1) // foo
Step 1: Add your environment variables to their appropriate file. For example, your staging environment could be called .env.staging, which contains the environment variables USER_ID and USER_KEY, specific to your staging environment.
Step 2: In your package.json file, add the following:
"scripts": {
"build": "sh -ac '. ./.env.${REACT_APP_ENV}; react-scripts build'",
"build:staging": "REACT_APP_ENV=staging npm run build",
"build:production": "REACT_APP_ENV=production npm run build",
...
}
then call it in your deploy script like this:
npm run build:staging
Super simple set up and works like a charm!
Source: https://medium.com/#tacomanator/environments-with-create-react-app-7b645312c09d
Make your life easier with dotenv-webpack. Simply install it npm install dotenv-webpack --save-dev, then create an .env file in your application's root (remember to add this to .gitignore before you git push). Open this file, and set some environmental variables there, like for example:
ENV_VAR_1=1234
ENV_VAR_2=abcd
ENV_VAR_3=1234abcd
Now, in your webpack config add:
const Dotenv = require('dotenv-webpack');
const webpackConfig = {
node: { global: true, fs: 'empty' }, // Fix: "Uncaught ReferenceError: global is not defined", and "Can't resolve 'fs'".
output: {
libraryTarget: 'umd' // Fix: "Uncaught ReferenceError: exports is not defined".
},
plugins: [new Dotenv()]
};
module.exports = webpackConfig; // Export all custom Webpack configs.
Only const Dotenv = require('dotenv-webpack');, plugins: [new Dotenv()], and of course module.exports = webpackConfig; // Export all custom Webpack configs. are required. However, in some scenarios you might get some errors. For these you have the solution as well implying how you can fix certain error.
Now, wherever you want you can simply use process.env.ENV_VAR_1, process.env.ENV_VAR_2, process.env.ENV_VAR_3 in your application.
For windows users this Stack Overflow question and top answer is quite useful on how to set environement variables via the command line
How can i set NODE_ENV=production in Windows?
Came across a nice tool for doing this.
node-env-file
Parses and loads environment files (containing ENV variable exports) into Node.js environment, i.e. process.env - Uses this style:
.env
# some env variables
FOO=foo1
BAR=bar1
BAZ=1
QUX=
# QUUX=
If you are using a mac/linux and you want to retrieve local parameters to the machine you're using, this is what you'll do:
In terminal run nano ~/.bash_profile
add a line like: export MY_VAR=var
save & run source ~/.bash_profile
in node use like: console.log(process.env.MY_VAR);
As expansion of #ctrlplusb answer,
I would suggest you to also take a look to the env-dot-prop package.
It allows you to set/get properties from process.env using a dot-path.
Let's assume that your process.env contains the following:
process.env = {
FOO_BAR: 'baz'
'FOO_🦄': '42'
}
Then you can manipulate the environment variables like that:
const envDotProp = require('env-dot-prop');
console.log(process.env);
//=> {FOO_BAR: 'baz', 'FOO_🦄': '42'}
envDotProp.get('foo');
//=> {bar: 'baz', '🦄': '42'}
envDotProp.get('foo.🦄');
//=> '42'
envDotProp.get('foo.🦄', {parse: true});
//=> 42
envDotProp.set('baz.foo', 'bar');
envDotProp.get('', {parse: true});
//=> {foo: {bar: 'baz', '🦄': 42}, baz: {foo: 'bar'}}
console.log(process.env);
//=> {FOO_BAR: 'baz', 'FOO_🦄': '42', BAZ_FOO: 'bar'}
envDotProp.delete('foo');
envDotProp.get('');
//=> {baz: {foo: 'bar'}}
console.log(process.env);
//=> {BAZ_FOO: 'bar'}
This helps you to parse the environment variables and use them as a config object in your app.
It also helps you implement a 12-factor configuration.
A very good way of doing environment variables I have successfully used is below:
A. Have different config files:
dev.js // this has all environment variables for development only
The file contains:
module.exports = {
ENV: 'dev',
someEnvKey1 : 'some DEV Value1',
someEnvKey2 : 'some DEV Value2'
};
stage.js // this has all environment variables for development only
..
qa.js // this has all environment variables for qa testing only
The file contains:
module.exports = {
ENV: 'dev',
someEnvKey1 : 'some QA Value1',
someEnvKey2 : 'some QA Value2'
};
NOTE: the values are changing with the environment, mostly, but keys remain same.
you can have more
z__prod.js // this has all environment variables for production/live only
NOTE: This file is never bundled for deployment
Put all these config files in /config/ folder
<projectRoot>/config/dev.js
<projectRoot>/config/qa.js
<projectRoot>/config/z__prod.js
<projectRoot>/setenv.js
<projectRoot>/setenv.bat
<projectRoot>/setenv.sh
NOTE: The name of prod is different than others, as it would not be used by all.
B. Set the OS/ Lambda/ AzureFunction/ GoogleCloudFunction environment variables from config file
Now ideally, these config variables in file, should go as OS environment variables (or, LAMBDA function variables, or, Azure function variables, Google Cloud Functions, etc.)
so, we write automation in Windows OS (or other)
Assume we write 'setenv' bat file, which takes one argument that is environment that we want to set
Now run "setenv dev"
a) This takes the input from the passed argument variable ('dev' for now)
b) read the corresponding file ('config\dev.js')
c) sets the environment variables in Windows OS (or other)
For example,
The setenv.bat contents might be:
node setenv.js
The setenv.js contents might be:
// import "process.env.ENV".js file (dev.js example)
// loop the imported file contents
// set the environment variables in Windows OS (or, Lambda, etc.)
That's all, your environment is ready for use.
When you do 'setenv qa', all qa environment variables will be ready for use from qa.js, and ready for use by same program (which always asks for process.env.someEnvKey1, but the value it gets is qa one).
Hope that helps.
Pretty much like some others answers but without any lib nor (bash) export.
I have some encrypted variables then I need to generate them on the fly.
The magic happens with set -a && ... && set +a which can be some content or a file.
#!/bin/sh
set -a
SOMEVAR_A="abcd"
SOMEVAR_B="efgh"
SOMEVAR_C=123456
set +a
# or
set -a && . ./file && set +a
I have a docker-entrypoint.sh with:
#!/bin/sh
node app/config/set-environment.js
ENVFILE=/tmp/.env
if [[ ! -f "$ENVFILE" ]] ; then
echo "File $ENVFILE is not there, aborting."
exit
fi
# here is where things happen
set -a && . $ENVFILE && set +a
if [ "${NODE_ENV}" = "development" ]; then
npx nodemon app/server.js
else
node app/server.js
fi
exec "$#"
While set-environment.js generates a (tmp) .env file
I was getting undefined after setting a system env var. When I put APP_VERSION in the User env var, then I can display the value from node via process.env.APP_VERSION
in case you're using visual studio code debugging feature, you can add "envFile": "${workspaceRoot}/.env" to launch configuration. This way you don't have to use dotenv.
{
"cwd": "${workspaceRoot}",
"command": "npm start",
"name": "Run be",
"request": "launch",
"type": "node-terminal",
"envFile": "${workspaceRoot}/.env"
},
Make a file called local-env and populate it with variables
PORT=80
DB_NAME=foo
SOME_URL=example.com
Now run node thusly:
source ./local_env ; node index.js
Use cross-env. It will save you a lot of headache
npm i -S cross-env
cross-env PARAM=value node ./index.js
That's usually good for non-credentials. For things like credentials and keys
it's better not to store hardcoded user id and password but use .env file which is not in repo and dotenv