Webpack-cli: Feature Request: Avoid `const DEBUG = argv.mode || "development" === "development"` in the webpack.config.js

[wood1986]

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

feature: Avoid const DEBUG = argv.mode || "development" === "development" in the webpack.config.js.

What is the current behavior?
In my case, debug and release version are sharing the same webpack.config.js because most configurations are identical. The only differences are the devtool and output. I believe other people will have the similar situation. You can say I can create two files for debug and release and then Object.assign them for release case but wouldn't be too much when comparing with one predicate statement?

Here are the examples

// webpack.config.js

const DEBUG = require("yargs").argv.mode !== "production";  // this is the problem
module.exports = {
  ...
  "devtool": DEBUG ? "nosources-source-map" : false,
  "output": {
    "filename": "[name]-[chunkhash].js",
    "libraryTarget": "umd",
    "path": path.resolve(__dirname, `dist/web/${DEBUG ? "debug" : "release"}`)
  },
  ...
}

// webpack.config.js

module.exports = (env, argv) => {
  const DEBUG = (argv.mode || "development") === "development";  // this is the problem
  return {
    "devtool": DEBUG ? "nosources-source-map" : false,
    "output": {
      "filename": "[name]-[chunkhash].js",
      "libraryTarget": "umd",
      "path": path.resolve(__dirname, `dist/web/${DEBUG ? "debug" : "release"}`)
    },
  }
} 

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

What is the expected behavior?
It should be two simple booleans for the mode info, stored in the webpack object.

// assume webpack has set these two flags based on --mode
webpack.mode.DEVELOPMENT = true;
webpack.mode.PRODUCTION = false;

Here is what I suggest

const DEBUG = webpack.mode.DEVELOPMENT
module.exports = {
  ...
  "devtool": DEBUG ? "nosources-source-map" : false,
  "output": {
    "filename": "[name]-[chunkhash].js",
    "libraryTarget": "umd",
    "path": path.resolve(__dirname, `dist/web/${DEBUG ? "debug" : "release"}`)
  },
  ...
}

If this is a feature request, what is motivation or use case for changing the behavior?
With this change, we do not have to put the predicate (argv.mode || "development") === "development" or require("yargs").argv.mode !== "production" inside our webpack.config.js. Here is the PR #351. But maintainers want to have more voice before moving forward.

Please mention other relevant information such as the browser version, Node.js version, Operating System and programming language.

[PlayMa256]

The same time it makes sense, reducing boilerplate, it's more like an improvement over development experience, this should be discussed a little further by the community but I'm going to give my five cents here.

Usually to differentiate development and production config files developers usually relies on process.env.NODE_ENV to manage which config should be applied and, unfortunately, this should be declared elsewhere anyways. Here we falls into the same problem described in this issue.

There is another option which is create different config files for each environment only overriding what is needed. Webpack actually suggests to use webpack-merge, a very handy tool which smartly merges different config files.

Both options requires either cross-env or "manually" setting NODE_ENV.

Since webpack embraces the #0CJS ideology, this feature would makes the config moves towards this idea.

Having this is not a bad idea, but not having this is not bad either. As I've said at the beginning, this would just improve devs experience.

[ematipico]

Assuming that we use one single file to support development and production, I usually tend to use NODE_ENV to separate the two environments.

The idea is nice but I wonder how we should get the information about the environment?

[PlayMa256]

From the --mode? We must assume a lot of things, but this is something we cannot assume at first. The developer has to give us some clue of what he is doing. It is expected to have --mode production if one is building for prod.

[ematipico]

Yes, this means that we have to ask to the user how he wants to keep track of the environment:

• NODE_ENV
• --mode (assuming that webpack exposes it)
• another way that is custom

[PlayMa256]

I do agree. In the PR opened related to this #351 wood1986 was able to use the mode exposed by the user. Although that can fail since the user could not pass a mode to CLI but can put that into the config file.

And yea, you right. We could ask the user on that...

[ematipico]

@wood1986 what do you think? Asking to the user how to track the environment would allow to us make the two logic (NODE_ENV and --mode) to coexist

[wood1986]

@ematipico I know --mode scenario but I do not know the NODE_ENV. Are you talking about some people run two separate commands like this?

export NODE_ENV=production
webpack

Or some people add process.env.NODE_ENV = 'production'; in the webpack.config.js

I assume all "webpack": "^4.0.0 users would use this single line command webpack --mode to build the app. Additionally, there is a warning message for users who has not set the mode

WARNING in configuration
The 'mode' option has not been set, webpack will fallback to 'production' for this value. Set 'mode' option to 'development' or 'production' to enable defaults for each environment.
You can also set it to 'none' to disable any default behavior. Learn more: https://webpack.js.org/concepts/mode/

I think we should not support NODE_ENV case. We should let users know this is the benefit of using --mode. In the long term, This can push users to use --mode and it is an incentive for users to fix the warning message.

[ematipico]

Yes something like this, or a command such as

cross-env NODE_ENV=development webpack ....

But yeah the result is the same.

Looking better and the documentation of --mode, I can see that webpack already does set the environment variable, so at this point I make up my mind and I think should stick with just --mode.

We are basically doing the same thing twice.

Although if we want to implement this feature, we will have to implement a "breaking" change for sure because --mode is only supported by webapck 4

[bitpshr]

It seems like this issue and the original PR were intended to ease the burden of having to conditionally configure many different rules based on an environment variable, e.g. 'stats': process.NODE_ENV === 'development' ? 'verbose' : 'minimal'.

Caching the value of --mode on the webpack object as suggested doesn't directly solve this issue. For example, such conditional configuration checks would still be required, they just wouldn't have to use process.NODE_ENV or process.argv directly and could instead use webpack.mode, e.g. 'stats': webpack.mode === 'development' ? 'verbose' : 'minimal'. This proposed change wouldn't eliminate production vs. development conditional checks, it'd just make them slightly cleaner and uniform.

I don't think we should implement this change.

[evenstensberg]

Using NODE.ENV is the best way, as the ecosystem in general relies on that variable to split dev and production builds/code.

[wood1986]

It seems like this issue and the original PR were intended to ease the burden of having to conditionally configure many different rules based on an environment variable, e.g. 'stats': process.NODE_ENV === 'development' ? 'verbose' : 'minimal'.

Caching the value of --mode on the webpack object as suggested doesn't directly solve this issue. For example, such conditional configuration checks would still be required, they just wouldn't have to use process.NODE_ENV or process.argv directly and could instead use webpack.mode, e.g. 'stats': webpack.mode === 'development' ? 'verbose' : 'minimal'. This proposed change wouldn't eliminate production vs. development conditional checks, it'd just make them slightly cleaner and uniform.

I don't think we should implement this change.

Do @bitpshr really understand real difference?

webpack.mode === 'development' ? 'verbose' : 'minimal' vs
webpack.mode.DEVELOPMENT ? 'verbose' : 'minimal'

I have been saying so many time we should not have the predicate statement and we just need a boolean flag.

[wood1986]

Using NODE.ENV is the best way, as the ecosystem in general relies on that variable to split dev and production builds/code.

I assume @ev1stensberg are talking about the cross-env. "webpack": "^4.0.0 has introduced --mode. According to the release log,

process.env.NODE_ENV are set to production or development (only in built code, not in config)

and the warning message of without specifying --mode. You should use --mode. Thus, you do not need cross-env.

[cnelson9000]

webpack.mode === 'development' ? 'verbose' : 'minimal' vs
webpack.mode.DEVELOPMENT ? 'verbose' : 'minimal'

@wood1986 These two examples are almost identical. I think they understand the difference but it’s just not a big issue. A boolean check instead of a string check saves 5 characters...just use —mode and NODE_ENV like @ev1stensberg and @bitpshr are saying with 4.x.

[wood1986]

It is about not only the characters but also the warning message if you use NODE_ENV only.