We Keep Coding

Toggle between dev and production mode

I would like to have a way to toggle between production and dev endpoints within from the phone settings. I am worried that this will mess up the cash and might display incorrect data. what's the best way to do it, please?

I was wondering the same thing!
In your code, you can use the __DEV__ global flag to differentiate between Dev and Production "mode".
Expo's Production switch is not a reliable way to handle environment switches (production and dev endpoints in your case). Why? 2 main reasons:
Production mode always minifies your code and better represents the performance your app will have on end-user's devices.
Development mode includes useful warnings and gives you access to debugging tools.
What if you want to have the flexibility to run the app against the Production endpoints you have, but still being able to access the debugging tools? You can't.
Here's my approach: I handle environment switches with .env files.
With Expo, I got my .env to work with the following:
Added babel-plugin-inline-dotenv to devDependencies:
npm install --save-dev babel-plugin-inline-dotenv
Added inline-dotenv to .babelrc:
{
"plugins": ["inline-dotenv"]
}
Added a .env file:
ENDPOINT="https://development"
Kudos for the .env set-up instructions goes to jdrydn.
Finally, use the environment variable in your code:
<Text>{process.env.ENDPOINT}</Text>
Plus, I have one more file .env-production (technically, I have also .env-staging in case you're wondering):
ENDPOINT="https://production"
The real caveat is when you want to run your app against the Production environment. You need to:
Copy .env-production content to the .env file.
Restart Expo's Metro Bundler and clear its cache (must be always restarted between .env changes). Do that either by running expo r -c or by pressing shift-r in your terminal to restart and clear cache while the Metro Bundler is running.
That's the most optimal approach I've been able to find.
PS: If you want to toggle between Dev and Production endpoints within you app - I'd simply use a js file with exported variables for each environment.

System environment variables ignored by Nuxt

My Nuxt project uses system environment variables to set client ids, secrets, urls, etc...
An example is in my nuxt.config.js where I set several properties with the following formula:
{
something: process.env.SOMETHING || 'something_for_dev'
}
Nuxt dev version is working fine because looks after the process.env.SOMETHING and correctly use something_for_dev.
Nuxt on staging has its own configuration on Azure and the SOMETHING env var is correctly set but suddenly it still continue using something_for_dev...
What should I do to let Nuxt use the sys env vars I set on my Server rather than the default used for dev? Thanks

Env variables are set build time, not runtime. So it will be the env variables that set during your build, which seems you do on your dev machine.
So you can either build with proper env variables or use nuxt-env module, which allows runtime variables, but keep in mind that it wont allow webpack to optimize dead code and environment variables used in nuxt-env are exposed client side, so if you store secrets use the secret config option

In addition to Aldarund comment above you could build a proper env variables in nuxt by following:
Use cross-env: npm install cross-env
In your project add a folder named environment
and under the folder you could have different environment (e.g. development, staging, production)
Your environment configs will have your baseUrl and other configs, let's say for development you could have your localhost then for the staging or production you could have your API_URL
defaults.json \\development
defaults.prod.json \\production
In nuxt.config.ts build > extend configure your different environment
This will replace defaults.json depending on which environment we will run our script in package.json.
In package.json configure your script to what environment will be run (e.g npm run start will use NODE_ENV=development which will use the defaults.json with baseUrl: http://localhost:3000 and npm run build will use defaults.prod.json with baseUrl: http://www.API_URL.com and other configs
For more detail you could see cross-env

Maven Profile concept in a NodeJS Project without MVN

Hello stakOverFlowers :D
I have a simple NodeJS WebApp that use Lerna to manage the project. So i have a package directory that contains n different projects each ones using different tasks runner tools.
I always use Maven Build Profile in java environment but for this NodeJS project maven will not be used.
So the question is...
Is there a way to reproduce the Maven Build Profile concept without using MVN?
In a nutshell i need to use a build profile in nodejs, without using MVN, to customize build for different environments such as Production v/s Development environments.
There's a way to do that?
thanks to all

you can do it by storing your configurations in a JSON file as key value pairs in the same way as you do in properties file in Java.
Then by someway or other invoke properties from the environment specific configuration file such as production.json or stage.json or qa.json.
One of the easy ways to do this is using this module named config
Using this you can pass NODE_ENV=production(or dev or qa whatever) and access relevant configurations. This will help you achieve environment profiling.
You can also store configurations in a JS file but I personally prefer a JSON file for storing configurations.
But if you're wondering for dependencies management that is done by package.json file which is somewhat similar to your pom.xml file.
For more details about it you might want to read this official documentation for it.

My solution, following the TGW advice, works!!
Just install the config module, and create a directory that containing .json files.
$ npm install config
$ mkdir config
$ vi config/default.json
Than if u are on a windows machine, choose your NODE_ENV using NODE_ENV=production and than execute your web app.
In your .js file put informations like yours dbConnection host and password.... and to retrieve it use:
var config = require('config');
var dbConfig = config.get('JsonItem.dbConfig');
..more details on https://github.com/lorenwest/node-config

Environment variable in Javascript (Gulp)

I have a local development machine and a test server.
Now I have an APP_ID that's being used in Javascript. I've been looking into ways that they kan differ on my local machine and on the test server.
Using Gulp
With gulp it's possible to add a flag on the command line:
gulp build --env=production
That way I can get the correct APP_ID from a file.
The only issue is with this approach I need to run my build on the server, at this moment I run gulp locally and upload the changes to my server
Is it okay to build on the server? Are there other ways to use environment variables in Javascript?

My suggestion is to not build on the server but build locally and then deploy to the server using one of the many deploy solution (es. deployer.org for php). Normally javascript NPM packages put build output even in GIT repository ready for use in other projects or for deploy.
For more info on how to use env variable in node (gulp run over node) see this page
For example in linux you can set env variable with export
app.js :
console.log(console.log(process.env.foo))
Then try
> export foo=app1
> node app.js
Res:
app1
Then try
> export foo=app2
> node app.js
Res:
app2
This is valid only if you run your code server side on node (ex on gulp).
If you are developing a client side library and you want to create different builds that targets different enviroments you have to instruct gulp to do so. In this case this is a guide that can help you

Two ways to Handle Environment Variables with Webpack in production server after a continuous integration

We're trying to run a ReactJs in production using Webpack as my build tool. For this purpose we use DefinePlugin to set environment variables.
new webpack.DefinePlugin({
'process.env.NODE_ENV': JSON.stringify('development'),
'process.env.API_URL': JSON.stringify("http://localhost:7852/"),
}),
However for security reasons I don't want to have sensible information in my source code, as example we don't want to put api keys or private urls in webpack configuration. So we are planning to store that values in the environment variables of the production server.
We do the Webpack build in a continuous integration server (Docker Hub). We want to compile in the Docker Servers but we don't want to put the settings in the Docker servers, we only want the settings in the production server. However when we set these values in my production server the result is undefined. Is there a way to set some configuration variables in Webpack to be handle during transpilation (there are several methods) and let the the production server handle the others? Any advice? Thanks in advance.

I've just run into the exact same problem. What I've found is at the time when webpack is run, is where the environment needs to be set in order to be visible by the application. This means that only what's on your CI server (which builds a docker image) will be available to webpack and consequently your app.
Unless your app routes requests through it's server, where the environment is available, to an api server, I couldn't think of a decent solution. What I've chosen to do is set the environment during my TeamCity build and have a separate build for each test and production servers which would create a separate docker image but using the same dockerfile.

You can use different webpacks for different environments, and move the sensitive configuration to environment variables. Your app can only see environment variables in a container if they are defined in the Dockerfile using ENV. If you change your app to read all sensitive information from environment variables, and have matching ENV instructions in your Dockerfile, you can specify them at runtime when you start the container.
E.g. in webpack:
new webpack.DefinePlugin({
'process.env.API_KEY': JSON.stringify(process.env.API_KEY || 'API_KEY environment variable not defined'),
...
In your Dockerfile add ENV API_KEY and when you run your container, you can pass the environment variables with -e: docker run -e API_KEY=ba3d4db....
Better still, if you have multiple sensitive values, define them in the Dockerfile and at run time pass them in an environment file using --env-file:
> cat Dockerfile
FROM ubuntu
ENV API_KEY \
ANOTHER_SECRET
> cat env.file
API_KEY=ab3da3bda4d4a4c4c4
ANOTHER_SECRET=shhh!
> docker run --env-file env.file -it temp bash
root#545d5945ab1b:/# echo $API_KEY
ab3da3bda4d4a4c4c4
root#545d5945ab1b:/# echo $ANOTHER_SECRET
shhh!
Then you can have the same Docker config for every environment, with different contents in env.file, and secure access to the file.