I'm having a problem with a NPM post-install script, the issue is that the build process ignores the configured NODE_ENV (set via cctrlapp x/y config.add) and always defaults to production. For what I've seen this was "resolved" two months ago by Heroku. From this issue, it seems that it should be transparent.
Is there something I must do to have access to my ENV variables during the build? Any workaround?
Thanks!
I found a workaround, from the different ENV vars the only one with a value during the build is DEP_NAME, but it's enough since we can extract the env from it: project/environment. This works in CloudControl, no idea if it would work in Heroku.
if ('DEP_NAME' in process.env) {
process.env.NODE_ENV = process.env.DEP_NAME.split('/')[1];
}
Related
Environment variables in NodeJS depenency
I have a NodeJS application which has a dependency of mine
my-base-module: git+https://myuser:mytoken#gitlab.com/organization/my-base-module.git#v1.0.0
I am also using the dependency dotenv, which in development I use the file .env and in other environments I pass the variables through docker environment variables
The problem I have, and I do not know why and how to solve it is that in my-base-module I do not share the same environment variables (and I need it to). It is like the variables loose the reference
require('dotenv').config();
const env = process.env.NODE_ENV;
for example in that bit of code the NODE_ENV variable inside my-base-module is undefined. However in the container is defined and with the right value
Update 1
I am requiring dotenv in both my-application and my-base-module. If I enter to the container and I do $ echo $NODE_ENV. I get production.
If my application process.env.NODE_ENV also holds production. But in the dependency process.env.NODE_ENV is undefined
I will try to do some github repositories to reproduce it
I was wrong, this works I made this small POC with these public repositories
https://github.com/agusgambina/try-base-module..https://github.com/agusgambina/try-application-dotenv
https://github.com/agusgambina/try-application-dotenv
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 trying to utilise the process.env.NODE_ENV to switch between the environments for my react native app, and am facing two issues here
1. Assigning parameter to NODE_ENV doesn't seem to change the env value straight forward,
executing the below command shows that it changed process.env.NODE_ENV value but doesnt seem to have changed the global.process.env.NODE_ENV
execution command:
NODE_ENV=development npm start -- --reset-cache
output: Please note, the second log statement still prints out development.
console.log("printing the changed value - ", process.env.NODE_ENV); // --> printing the changed value - production
console.log("checking the env content - ", process.env); // ---> checking the env content - { NODE_ENV: 'development' }
Workaround that i tried is to assign the process.env.NODE_ENV to the global instance,
global.process.env.NODE_ENV = process.env.NODE_ENV
Please do advise if this is a good approach to proceed with.
2. Assigning "Production" as a value to NODE_ENV throws Attempted to Assign to read only property error,
Execution Command:
NODE_ENV=production npm start -- --reset-cache
Please find image attached -
AssignToReadOnlyPropertyIssue
The problem your facing here comes from an erroneous assumption:
react-native doesn't execute javascript in the same way as node.
Let's consider the following npm script:
"scripts": {
"start": "node index.js"
}
When running SOME_VAR="some value" npm start, process.env will contain a entry for that environment variable, since it is running from the process where SOME_VAR was defined.
In react-native something different happens:
calling npm start starts the react-native packager which bundles your javascript code and then sends that javascript bundle to the installation in your emulator or device, where the bundle is in its turn executed. react-native's packager doesn't "forward" the environment variables defined where the javascript was bundled.
Hopefully there are packages that aid us to be able to keep using the same patterns we're used to using when developing node apps.
One I found really helpful was babel-plugin-transform-inline-environment-variables. This is a babel plugin that transforms process.env.SOME_VAR type calls to the value of SOME_VAR during bundle time.
The only headache I had with it was that when I was first trying to see how it worked I was changing the environment variables, but it only seemed to work "randomly". Turns out I was a victim of webpack's cache. If there are no changes in the code it is watching it won't update the bundle. I then learned I had to be aware of that
I am a beginner in Node and I see the following code in my project:
process.env.NODE_ENV
What is NODE_ENV and how can I get access to it or change it? It seems to pick up some values but don't know from where is it getting picked up.
Please let me know.
NODE_ENV is the name of an environment variable, and you can access and change it in your shell Ex: export NODE_ENV=development , you can change it when running your process, Ex: NODE_ENV=production node application.js, or you can change it in one of your shell's configuration files.
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.