3 comments

[ 2.9 ms ] story [ 18.1 ms ] thread
On the other hand you can just have Webpack target Node, which sort of results in the same thing with a Webpack bootstrap around it. With exactly the same downsides, but convenient if you're already using Webpack for your clientside code.

I've recently set up a project with server and browser JS (and some shared things), having both bundled by Webpack and just NPM scripts to glue everything together. It's nice to have a single powerful tool that can handle pretty much all of your bundling and transpiling needs, the mental overhead gets smaller that way.

Have things changed since http://jlongster.com/Backend-Apps-with-Webpack--Part-I ? It sounded like there were a ton of workarounds to get Webpack working on the backend.
It's not as much of a mess as it seems there. I started out with James Long's config as well but quickly simplified everything and ended up with the following (left out some project-specific stuff):

https://gist.github.com/Ambroos/8299d0c0d322cd3a736d

As most complex things in Webpack do, it still feels like a hack at first.

Using simply /^(?!\.|\/).+/i in externals is way easier than scanning the filesystem for module names and usually more reliable. You simply assume that everything that is accessed with a relative path is local, and everything else is an external module. Add libraryTarget: 'commonjs' to tell Webpack to simply use classic requires for externals and to bundle everything up in the end, and you're done. Add loaders and plugins to your own preference.

You end up with one giant Javascript file that, when ran through Node, does exactly what you expect it to (but still requires NPM dependencies externally, so you can't 'just' use the bundled file without npm install).