This isn't necessarily wrong (you can make Webpack use Babel and thus merge the first two steps, I think) but right now it feels extremely wrong to me. I'm not yet convinced Webpack is a good idea either -- especially because the documentation is a sketchy mess at this point.
Webpack (like browserify) was written to generate bundles for the browser, not modules for Node. I have been wrong in the past and would be willing to suspend my disbelief if I were able to find any reliable information on how you're supposed to use Webpack for Node, but right now my gut feeling tells me it's a really bad idea and the Node support is a hacky afterthought at best.
The only thing, really, is to stop thinking of webpack as something that turns node code into browser code, but of something that turns general code into platform-specific code.
I fully agree that this wasn't what webpack was originally designed for, but in practice there's nothing about webpack that makes this intrisically difficult. Personally, I just use DefinePlugin to define a boolean SERVER constant. It's set to true on the node build and to false on the browser build, and then in my code there's just some stuff like this:
if(SERVER) {
// node-only code
}
For the browser build, Webpack turns that into this:
if (false) {
// node-only code
}
And then UglifyJS removes it entirely.
React uses the same trick to differentiate between production and dev builds, so in practice most React+webpack users will already be doing something like this so it's not a complex step to add.
I manage the difference between test/dev/production builds in the same way, haven't yet found a downside.
FWIW, the React app I would be using Webpack for (currently using Browserify and Babel) doesn't actually do any server/browser checks, the entire difference is handled via two different entry points and a few module swaps for browserify in my package.json file.
I've only just looked into it but Part I seems to confirm my suspicions: the defaults provided by Webpack aren't really geared for server-side code and it still generates a single bundle and you need a hacky addon (`source-map-support` on NPM) to get readable stack traces.
This is also the spectral opposite of what bundling with browserify looks like, which in my projects so far usually consisted of a single line using the CLI. Judging by that, Webpack is to browserify what Grunt is to `npm run` -- and IMO that's a bad thing.
I'm pretty sure webpack is tons more powerful than Browserify though. It's a very impressive piece of software, the way it handles code splitting and similar things is just incredibly well done.
This is what I mean.
Normally your chain would be:
ES2015/JSX -(Babel)-> Node code -(Browserify/etc)-> Browser code
With Webpack's "require" magic you end up with this:
ES2015/JSX -(Babel)-> Intermediate code -(Webpack)-> Browser code & Node code
This isn't necessarily wrong (you can make Webpack use Babel and thus merge the first two steps, I think) but right now it feels extremely wrong to me. I'm not yet convinced Webpack is a good idea either -- especially because the documentation is a sketchy mess at this point.
Webpack (like browserify) was written to generate bundles for the browser, not modules for Node. I have been wrong in the past and would be willing to suspend my disbelief if I were able to find any reliable information on how you're supposed to use Webpack for Node, but right now my gut feeling tells me it's a really bad idea and the Node support is a hacky afterthought at best.