
Babel 6 plugin which allows to use webpack loaders - cybice
https://github.com/istarkov/babel-plugin-webpack-loaders
======
Ambroos
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.

~~~
sync
Have things changed since [http://jlongster.com/Backend-Apps-with-Webpack--
Part-I](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.

~~~
Ambroos
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](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_ ).

