What about a revamp?

[elfey]

Do you want to request a feature or report a bug?
Feature/revamp.

What is the current behavior?
Right now, there are three essential parts to a development process with Node.js:

1. Watch for changes
2. Transpile changes
3. Reload environment with transpiled changes

And this tool, much like Webpack 1.0, is confusing. There's both CLI and config, and sometimes they conflict with one another, or options exist via CLI that don't via the config.

What is the expected behavior?
It should be more clear on how to use this thing (and I don't think that can be done with documentation alone). Again, Webpack 2.0 is seriously straightforward and this should be too. Consider that this tool basically covers two of the three parts of the typical development process (watch and reload).

So I think similar to how Webpack 1.0 had its revamp with Webpack 2.0, this tool should go through a similar revamp/process. It's seriously essential to tens of thousands of developer's workflows.

[SpaceK33z]

Again, Webpack 2.0 is seriously straightforward and this should be too.

You don't say what exactly is not straight forward? There were a lot of changes to webpack-dev-server v2 to make it easier to use (config validation like webpack 2 has for one).

There are some more planned changes to make errors in your config more prevalent, see #615. For the CLI and Node.js differences there is a ticket, #106.

Note that there are plans to do a more complete rework, which will probably address your issues partially. The plan is to make dev-server a plugin to webpack. Another plan to make usage easier (if you don't use the CLI), is to remove the part where you need to manually add an entry for the dev-server client script.

There are also plans to move the CLI part to a separate repository (along with the webpack CLI part), see webpack-cli for more info. Note that it's not sure yet if we'll do this.

I'll make tickets about this soon and then close this issue since there is no specific action thing here.

[elfey]

@SpaceK33z those changes sound great. I'm speaking more in a general sense because I know a handful of developers who've had to debug this tool in various different ways.

Ideally this would be a type of plug-and-play solution. Developers could use a simple CLI command (without having to set too many flags/options), or configure a plugin via their config file, and have this work like magic.

In my team's case, after updating our Webpack 1.0 to Webpack 2.0, some of the features here now require a lot more configuration than they previously did and still don't work as expected (or it's not clear how we're supposed to configure them in the first place). A quick Google search of our problems brings up a bunch of different Github issues which all propose different solutions to the same problem, some of which work, or have worked in the past, and some of which were solutions specific to a developer's problem and don't work for the wider array of projects that exist out there.

So it feels very divided and unorganized.

And this leads me to believe that it's not a matter of documentation, but the design of the system/tool in the first place.

Again, I'm happy to say that the new Webpack 2.0 doesn't really have this problem, except for a few issues relating to this package.