CLI doesn't behave like Node API

[gaearon]

A lot of times when somebody has problems with webpack-dev-server CLI, I suggest them use Node API instead and their problem disappears. Here's two recent issues I've seen.

Take this sample project from gaearon/react-hot-loader#77.

Run node ./node_modules/webpack-dev-server/bin/webpack-dev-server.js --hot --port 8080. Change a file. HMR will work but will output Uncaught RangeError: Maximum call stack size exceeded on every update.

Then add a server.js that should by all means be identical to the call above:

var webpack = require('webpack');
var WebpackDevServer = require('webpack-dev-server');
var config = require('./webpack.config');

new WebpackDevServer(webpack(config), {
  hot: true
}).listen(8080, 'localhost');

Magically, this doesn't work at all. The reason is because WebpackDevServer doesn't read publicPath from Webpack config. I always end up passing it manually. Why is this necessary?

Okay, let's pass it manually:

var webpack = require('webpack');
var WebpackDevServer = require('webpack-dev-server');
var config = require('./webpack.config');

new WebpackDevServer(webpack(config), {
  hot: true,
  publicPath: config.output.publicPath
}).listen(8080, 'localhost');

Voila! RangeError is gone.

1. Why does CLI and Node API behave differently? One gives RangeError, another one works.
2. Why won't CLI infer publicPath from Webpack config?

[sokra]

The node.js API has no access to the webpack options. You just pass an Compiler object.

This has the effect that you have to do many things manually, i. e. publicPath or adding the HotModuleReplacementPlugin.

The CLI can do this things because it has access to the webpack options.

[gaearon]

Is there a reason Compiler can't expose its options?
Is there a reason we don't let WebpackDevServer accept options instead of compiler, so it creates compiler itself (and has access to options)?

[sokra]

Is there a reason Compiler can't expose its options?

It does expose it, but by design you shouldn't access it.

Is there a reason we don't let WebpackDevServer accept options instead of compiler, so it creates compiler itself (and has access to options)?

by design. This way we can write other compilers that work with the webpack-dev-server, i. e. the MultiCompiler...

[gaearon]

We can make publicPath required so people don't omit it by mistake in dev server config

[gaearon]

In general I think one of the usability issues with Webpack is it isn't strict enough in the configuration. For example you can write loader and it needs to be a string, or you can write loaders and it's an array, but even inside a single string you can chain loaders with !. Sorry for ranting, but this is something I'd love to see solved in 2.0 by demanding more strict (and uniform) over relaxed (and often, in the end, wrong) configuration.

[gaearon]

Another difference between CLI and Node API: with CLI, I can omit output.path, but Node API crashes if it's not specified.

[luisrudge]

I can't use the inline option as well :(

new WebpackDevServer(compiler, {inline: true}) doesn't work

[SpaceK33z]

This is a very old issue, but I still want to fix this.

Looking at lib/Server.js, it uses options.publicPath || "/". So "/" is the default value when using it from the Node API.
The CLI sets publicPath to the output.publicPath specified in the webpack config.

@sokra, do you think it makes sense to remove the default "/" value from options.publicPath, and throw an error when it is not set instead?

Another difference between CLI and Node API: with CLI, I can omit output.path, but Node API crashes if it's not specified.

This is probably getting fixed in #337.