[TheAceOfHearts]

I challenge your assumption that gulp + browserify is more straightforward than webpack. Your setup is not representative of a real application.

I setup a project scaffold [0] with a configuration that supports development, production, and testing environments. It has a heavily commented webpack config.

No tests? No asset cache busting by updating name references? Come on, those are basic requirements for a web project.

On top of that, webpack lets your dependencies be resolved as part of your code, instead of relying on certain files being in certain folders: e.g. your css and images.

[0] http://github.com/cesarandreu/web-app

[renke1]

Thanks for your project template. It looks really polished.

What is your experience in regard to running tests with Webpack?

* Can you test individual modules that use arbitrary loaders specified in your Webpack config?

* Can you run tests from the command line?

* Can you write your tests in ES6/7 (or anything else supported by Webpack's loaders)?

I was looking into combining jest with Webpack but every solution so far would only compile your module directly with Babel and therefore skipping the power of Webpack.

[TheAceOfHearts]

No huge issues with running tests that depend on webpack, but the developer UX is not outstanding.

If you want to be able to do everything, you'll have to configure more stuff. Honestly, I don't think it's worth the extra effort to try and configure things to work with every possible workflow. Just setup what you need, and then add stuff in as you find yourself wanting / needing it.

My advice is to avoid jest. It's too slow and clunky. If you want to stub modules, there's rewire-webpack. If you're using babel and ES6 modules you'll probably want to check out babel-plugin-rewire. I think there's a few other alternatives, but I haven't had the need for any of these so far.

On to your questions...

> Can you test individual modules that use arbitrary loaders specified in your Webpack config?

Yes. The solution I have is to maintain a single webpack config maker function that has a bunch of conditionals inside, and then I just use that function from all my configs. When you set options.TEST to true, it'll set the entry point to an empty object.

That means that my tests will be configured as close as possible to my production and development. The same loader config will be used for all the environments.

> Can you run tests from the command line?

Sure. In the web-app repo, it uses karma with phantomjs.

If you want to test your code using node... It's a bit more annoying, but also doable. I've previously set it up like this: create a test.js [0] file, set it as the entry-point in the webpack config, and use webpack context to include all the tests you wanna run, and finally point mocha to the output file. If you wanna use it in "live" mode, you can run webpack and mocha both with the watch flag.

If you just wanna run a single test... You can specify a single test as your entry-point, and then point mocha to it. Again, if you want "live" mode, you can set the watch flag on both mocha and webpack.

> Can you write your tests in ES6/7 (or anything else supported by Webpack's loaders)?

Yes. They use the same loaders as the rest of your codebase.

[0] https://www.dropbox.com/s/35ebqijrp9nqyj3/Screenshot%202015-...