Hi @amilajack (and @amireh). Thanks for your interest to contribute!

How about writing the block in the happypack package first (like in happypack/webpack-block.js): You can already publish and use it and then open a PR here when you think it works / it's stable?

I definitely see the benefit, we just have to come up with some kind of process here :)

Of course. I'd be happy to help. I should point out though that this is the first time I see webpack-blocks (nice concept 😄) so I don't have enough context.

I feel that adding the block definition in the main repository seems like the wrong spot, shouldn't webpack-blocks be the one concerned in providing support for it?

Also keep in mind that (unfortunately) HappyPack is a strange beast, somewhat like the extract-text-plugin. For an API, I would imagine decorating a block with happypack support, like:

const happyPackBlock = require('@webpack-blocks/happypack');

module.exports = createConfig([
  happyPackBlock(babel(), { ...happyRelatedOptions }),
])

We'd also need to take into account cross-loader options (like sharing a thread-pool between different HappyPack plugin instances) which I've pointed to in the ...happyRelatedOptions part. The block could make the necessary adjustments to the config such that we end up with the right plugin definitions and so on.

@amireh I think the main goal to focus on right now is to create a webpack block for happypack that works and is easy to use. We can then add it as package under the @webpack-blocks package scope :)

Unfortunately I on the other hand have got no experience with happypack 😉 But we could still try to team up here. I can improve the documentation on how to write webpack-blocks and answer your questions and you can try to contribute a block for happypack.

happypack's API really makes it rather hard to use / write a block for it (kinda like extract-text). But the good thing is that once it's done, it will be way easier to get happypack up and running :)

Btw: It's pretty new, so it's no surprise you haven't heard of it yet ^^

@amireh @andywer Is there any progress on this? I'm very glad of using webpack-blocks for my configs, but I couldn't find a way to build a working block with happypack, is something blocking this?

Hey @fenos.

There is two things to why it's not yet done:
a) It's got a rather low priority for me right now. Vote it up with a 👍.
b) I wasn't quite sure how the solution should look like, since happypack is quite complex to set up.

But at least for the latter reason I might have a solution:

module.exports = createConfig([
  happypack([
    babel(),
    sass()
  ])
])

Would be simple to use it at least, but not so simple to implement the happypack block, though.

@andywer Thank you very much for the fast response, as this is not your priority I would like to help out on this.

The example look promising, I'll give another try to build up the block! 👍

@fenos That would be nice. Won't be trivial, though.

I'd say that the happypack block would need to do this (but maybe there is another way):

• run each block we passed to it
• transform the returned config snippet
• dynamically construct new temporary blocks that return the transformed snippets
• dynamically call group() on those temporary blocks
• invoke this block group

That is some dirty business! 🙈 Maybe a slight modification to the under-the-hood core API might make things a little easier. Not completely sure how that would have to look like, though.

@andywer Cool, this is my first attempt for the block, which i think point to the 3rd step

Usage:

happypack([
    babel(),
 ])

However, this is not working, cause the current babel block doesn't return the config object, it instead return an empty object here

How would you go about it?

@fenos Yeah, the babel block emits the actual config from the post hook. You need to care for the post hook as well... 🙃

Btw, this is also a good reason why @webpack-blocks/core should somehow provide us an appropriate tool, so we don't have to fiddle with low-level stuff like that ourselves in the block.

Are you beginning to see why I wrote it won't be trivial? 🙈😅

@andywer I now got your point 😅 it looked like easy but many edge cases to cover 🐙
let's see what I can do about it, need to read webpack-blocks source code 😆 to get a better understanding.

@fenos I might have just come up with a working concept on how to implement the block 😉

https://gist.github.com/andywer/50e4dca95d816c8bd5cac28ea9b3b3a5

Haven't tried it yet, though.

@andywer Thanks a lots! I confirm that the snippet works, but I'm still having trouble to set the right configs for happypack here is how i tried to fill the missing function implementation:
Happy pack block pt.2

The configs looks good to me and webpack accept them correctly, but when the build finishes it throws the following:

Happy[loader0]: Loaded 0 entries from cache. (0 were stale)
Happy[loader0]: All set; signalling webpack to proceed.
Build completed in 5.645s

Time: 5795ms

ERROR in ./src/client.js
Module parse failed: /Users/Fabrizio/Documents/Code/gousto2frontend/src/nodeserver/node_modules/happypack/loader.js?id=loader0!/Users/Fabrizio/Documents/Code/gousto2frontend/src/nodeserver/src/client.js Unexpected token (30:2)
You may need an appropriate loader to handle this file type.
|       const reactRootDOM = document.getElementById('react-root')
|       ReactDOM.render(
|               <HotContainer>
|                       <AppCont
|                               history={history}
 @ multi (webpack)-dev-server/client?http://localhost:8000 webpack/hot/dev-server react-hot-loader/patch babel-polyfill ./src/styles/vendor/normalize.css ./src/client.js ./src/styles/base.css webpack/hot/only-dev-server
webpack: Failed to compile.

@amilajack Do you have any idea?

Usage

happypack([
    babel(),
]),

@fenos Looks to me as if the babel-loader was never invoked. Can you console.log() the resulting webpack config and post it here / put it in a gist?

@andywer here you go: webpack config generated

To me it looks good, can't catch the problem 😞

Config looks good to me as well. Let's see what @amilajack and @amireh say 😉

@fenos the config (dump I assume?) you linked look strange to me; HappyPack doesn't seem to have any loaders specified (state.loaders should not be an empty array if they were).

Is there any chance you can show the source config, or more precisely, how the happypack constructor options are being specified?

@amireh thanks for the response 👍 Here is the happypack block which will configure the Happypack instance:

https://gist.github.com/fenos/a3d69ff5060948700f9e0ce5ab2eda88#file-happypack-2-block-js-L31

There is definitely something not right, not sure which option I'm missing on the Happypack side.

Thanks for helping

@amireh At first I wondered about the empty state.loaders in the plugin instance as well, but since config.loaders is fine I assumed it would be filled when webpack actually runs...

I think I got it, I've pushed a patch to master that's ought to fix this.

Can you please test against the master branch to see if it resolves this as well?

@fenos Tell us when you had the chance to test it :)
(I would just npm i 'happypack@https://github.com/amireh/happypack.git#master' 😉)

@amireh I think it's faster if @fenos tests it, since he already has a working setup.

@amireh @andywer I confirm that it works now!! 🎉 thanks a lot! 👍
However somehow my build became slower with happypack handling the JS compilation, do you know why this happen?

Without happypack 69s with happypack (js loader) 79s using 4 threads

@fenos That's surprising. How many JS modules do you have and how many threads are you using for HappyPack?

That's very surprising for me too,
The project has: 1979 modules - using: 4 Threads

Curious, do you get different results if you use a vanilla webpack config (that is, without webpack-blocks)?

Any news, @fenos? I know, it's cumbersome. But we have made great progress on this issue in the last two weeks. Would be nice to finally have a solution 😊

Btw, is the code you try to bundle open-source or proprietary? Would be nice to have a minimalistic repo with the webpack.config.js, package.json and some source files to debug the issue. But I fear we will need to have quite a lot of source files to debug it...

Another idea:
@amireh I bet you got some projects where you can test webpack with happypack vs. without. How about I open a feature branch with what we have so far, publish the happypack block as some beta version and you try to use webpack-blocks and the happypack block in an existing project?

@andywer That sound good (Second Idea), I can make a PR with the working block, so that u can do a comparison between with / without happypack.

I'm pretty sure is not webpack-blocks the problem as it just builds up the configuration at run-time.

I kept the block for a while now and there isn't speed improvements with happypack so far, I'm really keen to help out with this 👍

Has anyone tried @diegohaz's https://github.com/diegohaz/webpack-blocks-happypack yet?

I guess we can close this issue now and discuss in his repo if necessary :)