Watch Options: Cannot read property 'poll' of undefineds

[birdwell]

Please note that this template is not optional. If you proceed with this form,
please fill out all fields, or your issue may be closed as "invalid."
Please do not delete this template. Please ask questions on StackOverflow or the
webpack Gitter (https://gitter.im/webpack/webpack). General questions, how-to
questions, and support requests will be closed.
Please do remove this header to acknowledge this message.

• Operating System: macOS High Sierra
• Node Version: v9.2.0
• NPM Version: 5.5.1
• webpack Version: 3.10.0
• webpack-dev-server Version: 2.9.6

• This is a bug
• This is a feature request
• This is a modification request

Code

TypeError: Cannot read property 'poll' of undefined
    at Server._watch (my_project/node_modules/webpack-dev-server/lib/Server.js:670:40)
    at Object.watchContentBase (my_project/node_modules/webpack-dev-server/lib/Server.js:322:14)
    at Server.forEach (my_project/node_modules/webpack-dev-server/lib/Server.js:372:22)
    at Array.forEach (<anonymous>)
    at new Server (my_project/node_modules/webpack-dev-server/lib/Server.js:371:41)
    at startDevServer (my_project/node_modules/webpack-dev-server/bin/webpack-dev-server.js:381:14)
    at processOptions (my_project/node_modules/webpack-dev-server/bin/webpack-dev-server.js:345:5)
    at Object.<anonymous> (my_project/node_modules/webpack-dev-server/bin/webpack-dev-server.js:489:1)
    at Module._compile (module.js:641:30)
    at Object.Module._extensions..js (module.js:652:10)`

  // webpack.config.js

'use strict';
const path = require('path');

module.exports = {
	entry: {
		index: [
			path.resolve(__dirname, './src/index.js')
		]
	},
	externals: [],
	output: {
		path: '/',
		filename: 'index.js'
		// publicPath: '/'
	},
	devServer: {
		contentBase: path.resolve(__dirname, './src'),
		watchContentBase: true
	}
};

  // additional code, remove if not needed.

Expected Behavior

npm start would start the dev server.

Actual Behavior

npm start throws this error.

For Bugs; How can we reproduce the behavior?

watchContentBase is the trigger for the bug.

For Features; What is the motivation and/or use-case for the feature?

[shellscape]

@birdwell your webpack config isn't optional. include that, or we'll have to close this as invalid.

[birdwell]

@shellscape Okay, I've updated the report. Thank you.

[shellscape]

I'm unable to reproduce using the watch-content base example, which is very similar to the config you pasted.

[birdwell]

'use strict';

// our setup function adds behind-the-scenes bits to the config that all of our
// examples need
const { setup } = require('../../util');

module.exports = setup({
  context: __dirname,
  entry: './app.js',
  devServer: {
    watchContentBase: true,
    contentBase: [
      'assets',
      'css'
    ]
  }
});

I cloned that repo you referenced and added watchContentBase. I then used webpack-dev-server command directly instead of npm run webpack-dev-server. That's with a fresh install of webpack-dev-server from npm. I was able to reproduce it.

1. Clone webpack-dev-server
2. Add watchContentBase to the example you referenced.
3. npm i -g webpack-dev-server and webpack
4. wabpack-dev-server inside that example folder we changed.
5. Got the polling error.

[shellscape]

I cloned that repo you referenced

That link was to a directory in this repo. So I don't know what you mean by that.

I then used webpack-dev-server command directly instead of npm run webpack-dev-server.

Then you were using a global version of webpack-dev-server?

I followed the same steps you did, including running using a global install of webpack-dev-server, and was unable to reproduce. You must have run into an edge case on your machine or environment, and will have to debug it on your end.

[birdwell]

I clone this repo and went into examples/cli/watch-content-base.
I used the global version of webpack-dev-server.

bird-2:watch-content-base Josh$ webpack-dev-server

It's starting to look like I'm seeing an isolated problem too. Thank you, @shellscape

[birdwell]

The options object passed into server for me is the following:

{ watchContentBase: true,
  contentBase: [ 'assets', 'css' ],
  before: [Function: before],
  host: 'localhost',
  publicPath: '/',
  filename: 'bundle.js',
  watchOptions: undefined,
  hot: false,
  hotOnly: false,
  clientLogLevel: 'info',
  stats: 
   { cached: false,
     cachedAssets: false,
     colors: { level: 2, hasBasic: true, has256: true, has16m: false } },
  port: 8084 }

watchOptions is undefined.

 (53) this.watchOptions = options.watchOptions;

That causes this.watchOptions to be undefined.

  const usePolling = this.watchOptions.poll ? true : undefined; // eslint-disable-line no-undefined
  const interval = typeof this.watchOptions.poll === 'number' ? this.watchOptions.poll : undefined; // eslint-disable-line no-undefined

That causes these lines to fail. There could be a bit more defensive and if options.watchOptions is undefined set this.watchOptions to an empty object instead. That way you could safely check the poll option on the watchOptions. Unless watch options is always suppose to be defined from the options object and it's something local I've done. What do you think? @shellscape

this.watchOptions = options.watchOptions || {};

[shellscape]

Very strange case indeed. Starting WDS from both methods, on my end, produces and empty object without having to explicitly set it. And no error occurs. I'd like to know more about why your environment seems to be failing to setup the options object properly, but in the mean time you could open a PR for this, and it would be a good first contribution.

[birdwell]

@shellscape thanks so much for helping me with this. I'm a fish out of water in trying to figure this out. Someone at my company manages webpack. This happened to me today. I will put my investigation hat and do some digging. I want to get more involved in open source.

[shellscape]

@birdwell for sure. the first step is to fork this repo (there's a button near the top right on the main/home page of the repo). then you can change that line you mentioned and commit it. go with a commit message of something like "fixes #1217: strange case with default watchOptions value" or whatnot. push your commit to your fork, and you should see a button for opening a pull request on your fork's main/home github page. We'll review it (it'll be quick because it's a small change), merge it, and publish it. And you'll get credit for the fix. ping me on twitter at this same name if you get stuck along the way.