Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Happypack block #126

Closed
wants to merge 2 commits into from
Closed

Happypack block #126

wants to merge 2 commits into from

Conversation

fenos
Copy link

@fenos fenos commented Mar 1, 2017

As discussed in the issue #14 will be very nice to have a happypack block wich allows us to easily implement Happypack features to improve the performance of the build.

@andywer found a neat way to implement the block using the webpack-block API, big thanks for that.

With a bit of delay I finish it up, so here you go.

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

Note:
I'm using the loader for a while now, and unfortunately, I haven't seen any improvements in terms of build speed in either watch mode and production build This Pr will also help to debug the problem.

* Takes an array, a function or something falsy and returns the array, the
* function wrapped in an array or an empty array, respectively.
*/
function toArray(value) {https://github.com/fenos/webpack-blocks
Copy link

@tb tb Mar 9, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@andywer
Copy link
Owner

andywer commented Mar 10, 2017

@tb Thanks :) And let's thank @github for letting the target repo owner edit files of PRs 😉

@andywer
Copy link
Owner

andywer commented Mar 10, 2017

@amilajack We still need some proof that it works as expected, esp. due to the performance concern. Can we do anything to help testing it?

@amilajack
Copy link
Contributor

@andywer What kind of testing would you like me to do? I can test this on some projects that I have that use webpack. Or do you want me to do performance testing?

@andywer
Copy link
Owner

andywer commented Mar 10, 2017

Just some rudimentary testing. Does it work (I suppose so) and is it faster than without :)

@fenos
Copy link
Author

fenos commented Mar 10, 2017

@amilajack @andywer I'm preparing a small react repo with webpack-blocks so we can measure the performance

@andywer : thanks for fixing the copy typo

@fenos
Copy link
Author

fenos commented Mar 10, 2017

@andywer @amilajack I was trying to find a react starter trough github so that i could just swap the webpack config to webpack-block, they are all relatively small, the build takes less then 4.0sec, so is not realistic. However there I could see that happypack did improve performance of 1s.

So I'm wondering if there is something wrong with the webpack config that we are using, or maybe not.

If you could try it in a bigger project then would help

@amilajack
Copy link
Contributor

@fenos A relatively big project that I would recommend is https://github.com/chentsulin/electron-react-boilerplate, which I am a maintainer of. In the project, we're having a lot of issues with slow build times. Also to have noticeable performance improvements, I think we have to add support for webpack caches and DLL's

@andywer
Copy link
Owner

andywer commented Mar 28, 2017

Any news?

@amilajack
Copy link
Contributor

Haven't had the chance to do this yet. I hope @fenos had a go at this

@soda-x
Copy link
Contributor

soda-x commented Mar 31, 2017

Any news?

@diegohaz
Copy link
Contributor

diegohaz commented Apr 8, 2017

Hey, guys. FYI, I've just published webpack-blocks-happypack based on this PR.

It has a DISABLE_HAPPY env flag so we can easily test if it's actually improving build speed.

On my tests, I'm using it on ARc, which is a relatively small project, and these are the build times on my Mac (4 CPUs):

  • without happy: ~11.5s;
  • with happy and without cache: ~10.5s;
  • with happy and cache: ~9.5s.

ARc only uses babel-loader though.

I'm also using that on a bigger project at work with babel-loader and css-loader. Time decreased from ~40s to ~30s.

If this PR get merged, I can deprecate that. I'm also fine with maintaining it as I'm using it on big projects in production.

@andywer
Copy link
Owner

andywer commented Apr 9, 2017

Hey @diegohaz. Sounds great, thank you!

We should look into that, esp. since it's already published.
And I promise I will come up with a community blocks list soon to keep track of all the awesome stuff that's not in the main repo 😉

@sapegin
Copy link
Collaborator

sapegin commented Aug 9, 2017

So what we’re going to do here? I’d close this PR, make a list of third-party blocks (already planned and needed) and link @diegohaz block there.

@andywer
Copy link
Owner

andywer commented Aug 9, 2017

I agree with @sapegin

@andywer andywer closed this Aug 9, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants