Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CLI doesn't behave like Node API #106

Closed
gaearon opened this issue Feb 13, 2015 · 9 comments
Closed

CLI doesn't behave like Node API #106

gaearon opened this issue Feb 13, 2015 · 9 comments

Comments

@gaearon
Copy link
Contributor

gaearon commented Feb 13, 2015

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
Copy link
Member

sokra commented Feb 13, 2015

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
Copy link
Contributor Author

gaearon commented Feb 13, 2015

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
Copy link
Member

sokra commented Mar 4, 2015

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
Copy link
Contributor Author

gaearon commented Mar 4, 2015

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

@gaearon
Copy link
Contributor Author

gaearon commented Mar 4, 2015

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
Copy link
Contributor Author

gaearon commented Mar 11, 2015

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

@luisrudge
Copy link

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

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

@SpaceK33z
Copy link
Member

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.

@SpaceK33z SpaceK33z added this to the Version 3 milestone Sep 22, 2016
shellscape added a commit that referenced this issue Aug 28, 2017
shellscape added a commit that referenced this issue Sep 27, 2017
…etizes optionsSchema (#1055)

* following #106, makes options.publicPath required via the API. alphabetizes optionsSchema

* fixing options validation tests

* reorg options schema

* refactoring options validation test to prevent needless duplication
@shellscape
Copy link
Contributor

Closing in favor of #616.

@michael-ciniawsky michael-ciniawsky removed this from the 3.1.6 milestone Aug 21, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants