Add HappyPack support

[davidmpaz]

From README.

HappyPack makes webpack builds faster by allowing you to transform multiple files in parallel.

Would be nice if we bring ideas on how to integrate best this, since it changes the way the loaders are declared. And also is good to get agreement on degree of integration.

Some points:

• When happypack is enable. All loaders will use it? or do we want to use it for some loaders instead?
• The same apply to happypack configuration options. Ex. Same amount of threads for all loaders?
• All of the previous influences on how many plugin instances will be added to configuration.

Some resources for reading
https://github.com/amireh/happypack/tree/master/examples

My five cents goes for a per loader configuration. Every loader can use it or not when enabled. this will add as many plugin instances as loaders we use, but in my opinion provides flexibility on loaders usage.

thanks in advance.

[weaverryan]

Probably "per loader"... though I'm not sure what the config would look like to say "yes ts-loader, no to babel". Also, it looks like some loaders might have issues or be unsupported: https://github.com/amireh/happypack/wiki/Loader-Compatibility-List... and there "may" be issues with ExtractText? amireh/happypack#119 (comment). We could also apply it to all of the loaders that we can... all the time. And then see if we need the ability to enable/disable it for some loaders.

The same apply to happypack configuration options. Ex. Same amount of threads for all loaders?

We should have 1 global HappyPack configuration, at least to start.

Overall, my biggest concerns is if this will introduce a lot of WTF, for small performance gains. Since HappyPack works with loader X, but not Y... it gives me a little bit of that impression. But, I've never used it :)

[davidmpaz]

I see you point :) ...

The use case I though of was to pass happypack configuration when enable***Loader() calls, if configuration is given we set up plugin for that loader, do nothing otherwise. This approach would even allow to introduce happypack incrementally for loaders.

My experience have been only with TypeScript. Currently my code base is not that big, popular vendors like bootstrap, jquery, etc. plus couple of modules, but this will grow more likely. Even with small code base time got reduced from 3-5 secs to 1s steady. So far for TypeScript works perfectly for me

Maybe we should wait until more support is added to happypack?

[weaverryan]

@davidmpaz well... there is (it appears) already pretty good support - it advertises babel-loader, sass-loader, style-loader, css-loader all as "Full". That would be pretty cool all on its own. If this can really help performance, that would be great. Performance of webpack builds in general is something that causes issues for some projects.

[davidmpaz]

With time I will workout an initial solution. I am afraid it will change lot of stuff though :(

[mastilver]

happypack alternative: https://github.com/webpack-contrib/thread-loader

[carsonbot]

Thank you for this suggestion.
There has not been a lot of activity here for a while. Would you still like to see this feature?
Every feature is developed by the community.
Perhaps someone would like to try?
You can read how to contribute to get started.