NODE_ENV not set on process.env

[okonet]

Do you want to request a feature or report a bug?

Bug

What is the current behavior?

Currently, mode only sets the value for NODE_ENV in the DefinePlugin but not changes the process.env.NODE_ENV.

For example, Babel depends on this env variable and when used with webpack --mode=production it will still run in development mode.

If the current behavior is a bug, please provide the steps to reproduce.

Running webpack --silent --mode=production && echo $NODE_ENV

This will NOT print anything.

Run NODE_ENV=production && webpack --silent --mode=production && echo $NODE_ENV

This will print production

What is the expected behavior?

Running webpack --silent --mode=production && echo $NODE_ENV should print production

[montogeek]

&& echo $NODE_ENV will show NODE_ENV value after previous command finished successfully, webpack will change it only while it runs, it doesn't change it for the entire system.

[okonet]

What is the way to log it during webpack process? It doesn’t seem to be set since Babel isn’t picking the right configuration which is based on that.

[paneq]

@okonet if the build takes sufficiently long you might want to try https://unix.stackexchange.com/questions/29128/how-to-read-environment-variables-of-a-process on linux

[montogeek]

I don't know exactly at what point exactly webpack sets process.env.NODE_ENV, also don't know if loaders should rely on it, by reading webpack/webpack#2537 (comment) one could conclude that it doesn't affect loaders source environment.

So you still have to set it at command level, so I would affect entire execution context.

[kzc]

AFAIK regardless of mode webpack does not set process.env.NODE_ENV.

• webpack 4: access the mode flag from webpack.config.js file webpack#6460 (comment)
• webpack 4: access the mode flag from webpack.config.js file webpack#6460 (comment)

If you want it set it has to be explicitly done by the user in the webpack config.

If this is not correct please show the line of code in the webpack 4 sources where this environment variable is set.

[okonet]

also don't know if loaders should rely on it

babel-loader doesn't rely on it per-se but since the loader executes babel-core which relies on it, it might break things right now.

If you want it set it has to be explicitly done by the user in the webpack config.

Then the documentation is misleading and needs to be updated? It should probably explicitly say that it only does new webpack.DefinePlugin({ "process.env.NODE_ENV": JSON.stringify("development") }),

[okonet]

But honestly I think that there is a problem with the mental model here. If something called in relation to node process.env then the mode should set it to that value during compile time.

[darshanags]

I think this bit of information should be reflected in the documentation: https://webpack.js.org/concepts/mode/. As it reads now - "Provides process.env.NODE_ENV with value XXXXXX", this lead me to believe that passing the mode as a CLI argument set process.env.NODE_ENV for the whole environment.

[okonet]

I’d argue it should actually set the variable to allow related tools be executed in the right context.

[Den-dp]

I was very surprised that --mode=production doesn't set process.env.NODE_ENV with value production within webpack.config.js but only provides this variable for your bundles.

So basically just a replacement for the old fashioned:

plugins: [
  new webpack.DefinePlugin({ "process.env.NODE_ENV": JSON.stringify("production") })
]

[mindplay-dk]

The manual literally says:

Provides process.env.NODE_ENV with value development

And the docs for sass-loader includes an example using:

process.env.NODE_ENV !== 'production' ? 'style-loader' : MiniCssExtractPlugin.loader

I guess this will silently use style-loader since process.env.NODE_ENV is always undefined?

I was hoping to do something similar, so what's the alternative?

How can I check which --mode is being run, so I can make variations in my webpack.config.js between development and production modes?

[mindplay-dk]

To others looking for a solution, I found it here: export a function instead of an object, and it will be called with parsed/normalized environment and argument objects.

(I'm submitting a PR for the sass-loader example, which doesn't work.)

[saivan]

Honestly, thanks a million @mindplay-dk, this was driving me nuts... I never realised there was an argv being passed in. Just to have it here:

module.exports = (env, argv) => {
     let production = argv.mode === 'production'

     ...
     return correctConfig
}

[hoainamcr]

In package.json
"scripts": {
"dev": "webpack --mode development --watch",
"build": "webpack --mode production",
}

In webpack.config.js
module.exports = (env, options) => {
const devMode = options.mode !== 'production';
return {
entry: ...
output: .....
module: {
....
{
test: /.(sa|sc|c)ss$/,
use: [
devMode ? "style-loader" : MiniCssExtractPlugin.loader,
"css-loader",
"sass-loader"
]
},
..........
}
.................
}
}

[Rudranand]

1. package.json
   replace ./conf/webpack.config.js with your webpack config file path.

"scripts": {
"test": "echo "Error: no test specified" && exit 1",
"dev": "webpack --config ./conf/webpack.config.js --mode development",
"build": "webpack --config ./conf/webpack.config.js --mode production "
},

2 . webpack.config.js

add plugin parameter value into webpack config.
module.exports = {
entry: ...........,
plugins: [
new webpack.DefinePlugin({
'process.env': {
'NODE_ENV': '"' + process.env.NODE_ENV + '"'
}
}),
],
output: {.....}
}

3. command to generate build

NODE_ENV=dev npm run dev or
NODE_ENV=prod npm run build

It will set the environment as you pass on command line.