Add HappyPack support #65
Comments
|
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.
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 :) |
|
I see you point :) ... The use case I though of was to pass happypack configuration when 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? |
|
@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. |
|
With time I will workout an initial solution. I am afraid it will change lot of stuff though :( |
This PR was squashed before being merged into the master branch (closes #99). Discussion ---------- Refactor plugin configuration Extract encore built in plugin configuration logic into plugin utils. First step toward allowing to be able to configure plugins through options and have more modular integration for plugins inside encore. From now on only public API with proper options is needed, for most cases. This changes are internals and tries to improve plugin architecture inside encore. Please take a look on it and feedback are welcome :). So far I see improvements for several issues: * #2 - Point .2 ...for plugins we should do the same as for loaders, from point of view of module split (utilities). * #63 - Better (more modular) integration of the plugin as well its configuration. * #65 - Same as #63 * #79 - Now it should be possible to pass options and/or check for flags to apply plugin or not. * #87 - Some small steps to make clean plugin more configurable. Public API still need to be changed though. thanks in advance. Commits ------- 65adfdc Refactor plugin configuration
|
happypack alternative: https://github.com/webpack-contrib/thread-loader |
|
Thank you for this suggestion. |
From README.
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:
happypackis enable. All loaders will use it? or do we want to use it for some loaders instead?happypackconfiguration options. Ex. Same amount of threads for all loaders?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.
The text was updated successfully, but these errors were encountered: