Set NODE_ENV during build

[mstade]

Expected Behavior

Some tools and libraries switch behavior, even at build time, depending on the value of NODE_ENV. For instance, you may see blocks of code fenced by a check for a particular value of NODE_ENV, which in certain situations – primarily for production builds perhaps – can be optimized away entirely for performance or other reasons. Here's an example:

if (process.env.NODE_ENV !== 'production') {
  console.debug('This could be optimized away entirely in production')
}

Smart builds would see this, substitute the value of process.env.NODE_ENV and see that the clause would translate into if ('production' !== 'production') { ... }, meaning the block could be removed entirely.

Thus I propose that ez-build sets NODE_ENV=production whenever the --production flag is enabled, to take advantage of this kind of optimizations.

Current Behavior

Currently, ez-build doesn't look to process.env.NODE_ENV at all, for anything.

Context

@DimitarChristoff brought this up while reviewing #37, providing some very valuable insight.

[DimitarChristoff]

Basically, you need to set this to production before calling webpack/babel etc as it will change the output of things like React and more, it will disable certain debugging features like React RedBox and console.error on propTypes checks.

Most webpack configs tend to utilise some logic around prod vs dev vs test in how they compose their configuration.

eg. https://github.com/davezuko/react-redux-starter-kit/blob/master/build/webpack.config.js

[mstade]

The proposal here could use some color. The idea is to set NODE_ENV to production whenever the --production flag is used, but only if NODE_ENV hasn't already been set. If NODE_ENV has been set already, we should leave it alone.

In the following example, the NODE_ENV value would be set to production

ez-build --production # This sets NODE_ENV to `production`

In this example however, the NODE_ENV value would be left alone, and remain as wibble throughout the execution of ez-build:

NODE_ENV=wibble ez-build --production # NODE_ENV is left alone, i.e. `wibble`

If the --production flag is not set, i.e. we invoke ez-build without arguments or with the --interactive flag instead, we may want to set another value. My suggestion would be to set it to development then, and not really make the distinction between an interactive development build, or one shot development build.