configuration has an unknown property 'error'

[patrik-simunic-cz]

Operating System: MacOS Sierra (10.12.6)
Node Version: v8.6.0
NPM Version: 5.3.0
webpack Version: ^3.6.0
webpack-dev-server Version: ^2.9.1

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

Code

webpack-dev-server throws this error message:

Invalid configuration object. webpack-dev-server has been initialised using a configuration object that does not match the API schema.
 - configuration has an unknown property 'error'. These properties are valid:
   object { hot?, hotOnly?, lazy?, bonjour?, host?, allowedHosts?, filename?, publicPath?, port?, socket?, watchOptions?, headers?, clientLogLevel?, overlay?, progress?, key?, cert?, ca?, pfx?, pfxPassphrase?, requestCert?, inline?, disableHostCheck?, public?, https?, contentBase?, watchContentBase?, open?, useLocalIp?, openPage?, features?, compress?, proxy?, historyApiFallback?, staticOptions?, setup?, before?, after?, stats?, reporter?, noInfo?, quiet?, serverSideRender?, index?, log?, warn? }

configuration has an unknown property 'error', though I don't have any property 'error' in my webpack.config.js (as can be seen bellow).

webpack.config.js

const path = require('path')
const webpack = require('webpack')
const CleanWebpackPlugin = require('clean-webpack-plugin')

module.exports = {
    entry: {
        bundle: path.resolve(__dirname, 'src/index.jsx'),
    },
    output: {
        publicPath: '/',
        path: __dirname + '/dist',
        filename: '[name].[chunkhash].js',
    },
    devServer: {
        host: '0.0.0.0',
        port: 8088,
        historyApiFallback: true,
    },
    module: {
        loaders: [{
            test: /.jsx?$/,
            loader: 'babel-loader',
            exclude: /node_modules/,
            query: {
                presets: ['es2015', 'react', 'stage-0'],
                plugins: ['transform-runtime'],
            },
        }],
    },
    plugins: [
        new CleanWebpackPlugin(['dist'], {
            root: path.resolve(__dirname),
            verbrose: true,
        }),
        new webpack.optimize.CommonsChunkPlugin({
            name: 'commons',
        }),
    ],
}

I'd normaly say that this is a problem on my side, but I've double checked the configuration many times and many times removed webpack and webpack-dev-server and installed them again, but this error stays... so I suppose this may be a bug in webpack-dev-server. Strange thing is, when I run webpack, it compiles without any error and bundles everything as it's supposed.

Expected Behavior

webpack-dev-server should compile and bundle the code and start dev server.

Actual Behavior

webpack-dev-server throws misconfiguration error.

For Bugs; How can we reproduce the behavior?

Run webpack-dev-server with the configuration snippets above.

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

EDIT:

I'm using webpack-dev-server via the CLI

EDIT 2:

Here is a simplified repo with replicated error: https://github.com/7h3w4rd0c70r/wds-misconfiguration-error

[shellscape]

@7h3w4rd0c70r are you using webpack-dev-server via the CLI or the API?

[patrik-simunic-cz]

@shellscape via the CLI

[shellscape]

@7h3w4rd0c70r in that case we'll need a stripped-down repo from you to reproduce. I'm afraid we won't be able to triage this issue without one.

[patrik-simunic-cz]

@shellscape Ok, I've created a repo with replicated error. It has the exact same webpack configuration I'm using on project and gives the exact same error.

Here: https://github.com/7h3w4rd0c70r/wds-misconfiguration-error

[patrik-simunic-cz]

Ok, after more digging, I've found an answer buried by google. Here it is: https://stackoverflow.com/a/46527969/5367254

Seems like global and local webpack-dev-server are killing each other. When I run ./node_modules/.bin/webpack-dev-server everything works just fine.

[patrik-simunic-cz]

But I still think this is a bug. At least you should get a different and appropriate error message. This is a problem of conflict between global and local packages, but you still get meesage

Invalid configuration object. webpack-dev-server has been initialised using a configuration object 
 - configuration has an unknown property 'error'. ...

You should get an appropriate message, because this can and does lead to thinking that there is something wrong with your configuration..

@shellscape What do you think?

[shellscape]

We've got a known-issue with global versus local in the CLI. The fix for this was part of the refactor of the CLI code in the beta branch https://github.com/webpack/webpack-dev-server/blob/beta/cli.js#L19. I've been resisting doing double the work but this has popped up a few times more than I would consider to be isolated. Unfortunately I haven't been able to reproduce the global/local conflict on my machine (and your test repo doesn't throw an error for me, but I have no doubt it is on your machine).

If you can open up your global and local webpack-dev-server directories and manually add a return after this line: https://github.com/webpack/webpack-dev-server/blob/master/bin/webpack-dev-server.js#L20, that might fix it. Otherwise we're going to have to try and backport the code from the beta branch into the CLI code on master.

[shellscape]

And forgot to mention, using webpack-dev-server without the node_modules path in an npm script to start it up should work as well.

"scripts": {
  "dev": "webpack-dev-server"
}

and

npm run dev

[patrik-simunic-cz]

@shellscape Running the dev server from package.json scripts works perfectly! Thank you :)

Al right, so it's a known issue, thats good. Well, when are you planing to release the version with the fix? Now I know what the problem is and how to 'solve' it, so I can wait (even a long time). But I'm just afraid that somebody else could end up with a few hours/days of debugging of a working code..

[shellscape]

@7h3w4rd0c70r the beta will probably take a few more weeks before it's ready for a publish, and even then it's going to be on the @beta tag in npm. A workaround is fine, but someone affected by this bug needs to step up and try to help find a fix, because I've as yet been unable to reproduce it. That's why I suggested opening up those modules on your machine and seeing if adding that return; fixed it for you.

[patrik-simunic-cz]

@shellscape Ok, So I've done as you wanted and it seems like it solved the problem. Since you can't see it on your machine, I've recorded the fix for you: https://www.youtube.com/watch?v=LiRMrWy4G-c

[shellscape]

@7h3w4rd0c70r that's so awesome! thanks for recording that!

OK so you have the option of creating a PR with that change to get commit credit for it, or I'll be happy to include your username in a commit and take care of it from my end. Which would you prefer?