Clarification on env vars?

[VS]

I've gotten myself mixed up and I could use a sanity check. Could you explain again why it's necessary to pass NODE_ENV to Webpack? I must be missing something but where is it not using the same process?

const webpackConfig = require('../config/webpack.config.js')(process.env.NODE_ENV || 'development');

// and

module.exports = (env = 'production') => {
...
}

[Manuel Bieh]

Oh that's a bit complicated. Let me try:

In scripts/start-client.js we have:

const webpackConfig = require('../config/webpack.config.js')(process.env.NODE_ENV || 'development');

That means we're using development as environment by default unless we explicitly override it by setting NODE_ENV to production. This is because start here means to literally start the dev server. So we usually don't want to have a production build when we're developing because it's much slower to build for production. We still have the option to start a dev server with the production build by setting NODE_ENV=production.

In scripts/build-client.js we have:

const webpackConfig = require('../config/webpack.config.js')(process.env.NODE_ENV || 'development');

This is where the production build is created. It works the other way round: it is production by default, because when we're building, we usually want to create a production build, not a development build. Production builds take longer but they're more optimized for smaller file size and meant to be deployed somewhere.

The default env parameter in webpack.config.js/index.js itself is set to production so we are able to use tools like webpack-bundle-analyzer to always build a production build by default without having to explicitly pass --env=production as CLI parameter.

Does this make sense?

[VS]

Aah, gotcha! I had been thinking that it was there to pass that env var from process to process or something but that didn't make sense. It's just for conveniently managing the default NODE_ENV and Webpack builds. Thanks 👍