V2 -- Divide env config into appEnv and nodeEnv

[sthzg]

Currently we set the NODE_ENV by mapping 1:1 to our Webpack configs. When working with multiple environments (e.g. dev, staging, dist) I found the requirement for finer control. E.g. to achieve this

dev     -> NODE_ENV=dev,        APP_ENV=dev
staging -> NODE_ENV=production, APP_ENV=staging
dist    -> NODE_ENV=production, APP_ENV=dist

In this example, staging and dist should both build with production optimizations (e.g. webpack -p and NODE_ENV=production). However, staging may differ in other conditional flags used throughout the app. This means, inside the project I need to distinguish between code targeted for staging and production, which I do by means of the APP_ENV setting.

Initially I was using the setting from src/config/<env>.js to pick appropriate values. However, in the case of dynamic requires Webpack would not eliminate dead code that way, so I'd propose using the DefinePlugin and introduce two changes to the configs:

// Somewhere inside conf/webpack/Staging.js
get env() {
  return process.env.NODE_ENV || 'production';
}

get appEnv() {
  return process.env.APP_ENV || 'staging';
}

this.config = {
  plugins: [
    new webpack.DefinePlugin({
      'process.env': {
        NODE_ENV: JSON.stringify(this.env),
        APP_ENV: JSON.stringify(this.appEnv)
      }
    }),
    // ...
  ]
};

This way, process.env.APP_ENV becomes available in code and everything inside the branch will be eliminated from the bundle size when the condition is not met (I am using it for things like requiring gobal mocks, adding dev routes, dev components, etc.).

@weblogixx would this addition be okay for you?

[weblogixx]

Hi @sthzg, more than ok. I use it nearly the same way in some current projects where I use the global conf to set api url targets for dev, staging and production usage. Currently, I just copied the base dev config and adjusted it accordingly (which was way harder when using v2 of the generator). For me this is totally fine.