Webpack-dev-server: WatchOptions passed from command line don't override config

[eckdanny-osi]

• Operating System: macOS 10.12.6
• Node Version: v8.8.0
• NPM Version: 5.4.1
• webpack Version: 3.8.1
• webpack-dev-server Version: 2.9.3, .2.9.7 (both)

• [x] This is a bug
• [ ] This is a feature request
• [ ] This is a modification request

Code

  // webpack.config.js
{
   ... 
   watchOptions: {
      ignored: /node_modules/
   }
}

webpack-dev-server --progress --color \
    --config path/to/config.js \
    --host 0.0.0.0 \
    --public localhost:3035 \
    --port 3035 \
    --watch-poll 500 \
    --watch-aggregate-timeout 300

Expected Behavior

Command line arguments for watchOptions should be used

Actual Behavior

I don't think they are.

For Bugs; How can we reproduce the behavior

Invoke from CLI as above.

Notes

Got here from https://github.com/rails/webpacker/issues/1045.

[shellscape]

The code in master would seem to disagree with this assessment.

https://github.com/webpack/webpack-dev-server/blob/master/lib/Server.js#L53

https://github.com/webpack/webpack-dev-server/blob/master/bin/webpack-dev-server.js#L260

The example for watch-content-base also works as expected.

And the docs don't show the flags as options that you expect to be working. Your watchOptions should be in a config.

This looks like a classic case of misuse.

[eckdanny-osi]

@shellscape is the CLI's --help output incorrect or are my expectations incorrect?

$ ./node_modules/.bin/webpack-dev-server --version
webpack-dev-server 2.9.7
webpack 3.8.1
$ ./node_modules/.bin/webpack-dev-server --help | grep watch
  --watch, -w  Watch the filesystem for changes                        [boolean]
                      [boolean] [default: It's enabled by default when watching]
  --watch-stdin, --stdin     close when stdin ends                     [boolean]
  --watch-aggregate-timeout  Timeout for gathering changes while watching
  --watch-poll               The polling interval for watching (also enable
  --watch-content-base    Enable live-reloading of the content-base.   [boolean]

[eckdanny]

Can't speak for most webpack-dev-server consumers, but personally i tend to reference man pages and --help output 1st and web documentation if I need further explanation.

My expectation was that CLI flags take precedence and were reconciled with config somehow. I think myself (and potentially others) are either misinterpreting the --help output or perhaps the watchOptons-related flags indicated from --help are inaccurate?

[shellscape]

That's a personal choice of course, but I'd highly recommend reading the actual docs next time before submitting an issue for any project. I don't know as if it holds true that man and --help are the definitive source of info for modern-day tools outside of some hardcore CLI idealists.

None the less, what we have here is a display bug resulting from combining webpack's CLI configuration with webpack-dev-server to get some common config for free. See https://github.com/webpack/webpack-dev-server/blob/master/bin/webpack-dev-server.js#L54

Unfortunately that's adding flags from webpack that webpack-dev-server doesn't support. The docs for this module are correct, the output on the CLI is not. We'll track a new issue to see if we can resolve that. But the takeaway here is to always check the actual docs.

[shellscape]

_I'd neglected to put this in the response above, but want this to stick out for others who might happen across this issue in the future_

Note the first three lines of the CLI output:

webpack-dev-server 2.9.7
webpack 3.5.6
Usage: https://webpack.js.org/configuration/dev-server/

The important bit there is Usage: https://webpack.js.org/configuration/dev-server/ as the CLI is pointing users towards the proper docs even in the --help output.

[ghost]

@shellscape Thanks for taking the time to develop a valuable tool and taking the extra effort to document it.

What @eckdanny-osi did may not be how you operate, but it is a very common pattern for a huge group of users "out there" (that's how I got here):

• If you are on a command-line interface, the first thing you do is "man tool" or "tool help", "tool -h", etc.
• And if the output is too large, the first natural thing to do is grep the output or "Cmd + F"
• Also, properties from the CLI overriding default values or configurations is the common behavior for most CLI tools, it's the "least surprising behavior"

You are of course free to deviate from the pattern, may I suggest to simply remove the whole output of "--help" and replace it with the "Usage" link? That would be easier than trying to change people to abandon behaviors that have been proven useful since at least the late 1970's