Webpack-cli: Discussion: "Used in Production" Odd Question and Provides Sub-Optimal Guidance

[larkintuckerllc]

webpack: 2.5.1
webpack-cli: 1.3.2

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

bug; hesitated at first to call this a bug as nothing fails, but it provides (in my opinion) an sub-optimal webpack configuration (so in this case is a bug).

What is the current behavior?

When running webpack-cli init one of the questions is:

_? Are you going to use this in production?_

And when you provide Yes the default name of the webpack configuration file is now _prod_.

_Name your 'webpack.[name].js?' [default: 'prod']:_

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

provided above

What is the expected behavior?

First, asking if it is going to be _used in production_ seems like an odd question. In the end, we are all working towards learning how to build production code. Seems like an unnecessary question.

That aside, having the generator default to creating a separate file _webpack.prod.js_ in this case would lead one to believe that it is best practice to have multiple configuration files (say one for development and one for production).

Looking through the webpack documentation (am working on yet another tutorial on webpack myself - _webpack By Example_), seems like the new way of distinguishing between development and production builds is to use the --env flag. https://webpack.js.org/configuration/configuration-types/

[evenstensberg]

Hi! Yep, you can read about why we ask for prod here:

https://github.com/webpack/webpack-cli/blob/master/INIT.md

I don'tthink that it is an odd question at all, let's keep this open for some weeks to see what people has to say!

I agree about the env flags, they should be used in some cases.

[larkintuckerllc]

First, I am all onboard with creating tools / resources that allow folks take control of their own webpack configuration; so I applaud this effort. I have a number of friends of mine who outsource their webpack configuration to some third-party tool, e.g., redux-cli, and ending up spinning their wheels when they have problems with their build process because they don't know anything about webpack.

That being said, I really see the _webpack-cli init_ as a tool to get folks up and running with a functional webpack configuration that implements best practice techniques. As folks become more experienced with webpack, the tool become irrelevant as they develop their own templates for their own purposes.

To that end, seems that a minimally functional webpack configuration has both a development and production work-flow. And, since it is sloppy to have to manage multiple configuration files with duplicated content (introduces opportunity for errors), it seems like a best practice to use a single configuration file and pass flags to control development or production builds.

In particular, in a series of articles that I have been writing on getting up to speed on _webpack_ - I use the _webpack-cli init_ as my starting point but add in what I would consider a true minimal configuration. The specifics are

Development Build Process:
./node_modules/.bin/webpack-dev-server --open

Production Build Process
./node_modules/.bin/webpack -p --env production

Relevant section in _webpack.config.js_

[text-obmitted]
module.exports = function(env) {
  return ({
    devtool: env === 'production' ? 'source-map' : 'cheap-eval-source-map',
[text-obmitted]

[nilliams]

Agree the question is confusing. I answered 'Yes' to the production question first, thinking like you 'of course I want to use it in production'. (It's also the default answer - capital Y in Y/n).

But this was a mistake, as I actually wanted a single webpack.config.js, and feel that's what most will want.

Think it has a negative impact on the 'first experience' as is.

[thescientist13]

Would it make sense for the CLI to generate webpack configuration per the recommendation of webpack's advanced usage documentation? I find in general this helps make understanding webpack a little easier by distinguishing what configurations are required for which parts of the build process and in general helps keep things organized.

I think prompting for the name of the config file could removed if this was implemented.

[evenstensberg]

In a newer version, we're omitting asking for the name and we set defaults more intuitively!