This is just plain untrue. The trick is simply to make Webpack generate a special build for Node.js that doesn't access the DOM.

With oldschool webpack style-loader, all you need is the well documented & supported ExtractTextPlugin to save the .css to a separate file, and there's nothing left for node to choke on. I'm not sure whether the same works as easily for the OP's idea though, but at a first glance I don't see why not.

The only real disadvantage is that you're feeding Node webpack-generated code, and not vanilla JS files. I've yet to find the real big problem with this, though, other than a slightly slower save-build-reload cycle.

> The only real disadvantage is that you're feeding Node webpack-generated code, and not vanilla JS files.

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.

Ah, I see your point. That said, Webpack works great with Babel indeed, so in practice this becomes:

cross-platform ES2015/JSX --(Babel+Webpack)--> Browser code & Node code

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.

Have you read Backend Apps with Webpack?

http://jlongster.com/Backend-Apps-with-Webpack--Part-I

http://jlongster.com/Backend-Apps-with-Webpack--Part-II

http://jlongster.com/Backend-Apps-with-Webpack--Part-III

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.

Heck, the final configuration file is a convoluted mess and the steps taken to arrive there aren't entirely obvious: http://jlongster.com/Backend-Apps-with-Webpack--Part-I#p28

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.

I use Webpack for isomorphic code. The trick is to hook up loaders in node via:

    require.extensions['.css'] = loaderFunction

I thought require hooks were deprecated (although they are likely to stick around for a while because legacy support)?

I'm working on a preprocessor that addresses that issue. It consumes JS objects/arrays and spews out CSS with localized class and animation names and a unmangled -> mangled dictionary.

http://j2c.py.gy

The stylesheet can be inserted in the VDOM, very easily in modern browsers (IE9+). The isomorphic scenario is more involved when IE8- support is required because you can't just have `<stlye>{styles}</style>` work out of the box on the client, you must access the DOM element and set its `.styleSheet.cssText` property.

Yahoo's Flexible yo generator creates an isomorphic application using web pack. https://github.com/yahoo/generator-fluxible

I'm not sure of the details or how it manages to make it work server side (if it does at all), but they do use Webpack for /something/ in an isomorphic app.