amireh / happypack

Happiness in the form of faster webpack build times.
MIT License
4.23k stars 124 forks source link

Rebuild time significantly slower in Webpack 4 #220

Open drewjenkins opened 6 years ago

drewjenkins commented 6 years ago

Hello,

I added Happypack, and it cut down my initial build time from 74116ms to 41541ms, great! Then, on the first hot module replacement of the application the rebuild time increases from 10656ms to 79796ms, more than cancelling out the benefits of the initial build.

I can attach my webpack config if you want, but I'm guessing this is working as expected. These results would lead me to believe that I should only be using happypack while generating my production output, not for the development environment. Am I correct in thinking this?

amireh commented 6 years ago

On the contrary, it was meant for use in development to save time when you have to keep restarting webpack (e.g. when changing config or switching branches.)

But I'm sorry to hear that. Are you using the extract-text plugin by any chance?

drewjenkins commented 6 years ago

Thanks for the response! We do use an ExtractTextPlugin

{
  test: /\.s?css$/,
  use: ExtractTextPlugin.extract({
    fallback: 'style-loader',
    use: [
      'css-loader',
      {
        loader: 'postcss-loader',
        options: {
          plugins: () => [
            require('precss'),
            require('autoprefixer'),
          ]
        }
      },
      {
        loader: 'sass-loader',
        options: {
          includePaths: [
            './node_modules/foundation-sites/scss/',
            './node_modules/emojione-picker/css',
            './node_modules/react-s-alert/dist/'
          ],
        },
      },
    ]
  }),
},

I tried hooking up Happypack to it, but couldn't get it working correctly, is that my issue? :)

Also, while I have you here, is it safe to use HappyPack for our production build as well? Currently, we have all of our loaders in a common.config.js file, so it'd be a bummer to have to split it out into the dev and prod configs if we don't need to

amireh commented 6 years ago

We do use an ExtractTextPlugin

Personally we use it only in production since it ramps up the build time quite heavily (+ getting hot-reload to work with it is even more work.)

Another alternative is now available for webpack4 and I suggest you look into it: mini-css-extract-plugin - I've used this successfully on a small project in place of extract-text and it works even with dynamic chunks.

I tried hooking up Happypack to it, but couldn't get it working correctly, is that my issue? :)

There's a long history with happypack and extract-text compatibility, it's not very straightforward. If you look through the issues on this project you should be able to find tips on how to make it work, but there are also examples available for webpack1/2/3/4 if you want: https://github.com/amireh/happypack/tree/master/examples/extract-text-webpack-plugin

The webpack config code is found under versions/* and the source code of the example under src/.

Also, while I have you here, is it safe to use HappyPack for our production build as well? Currently, we have all of our loaders in a common.config.js file, so it'd be a bummer to have to split it out into the dev and prod configs if we don't need to

We use it in all environments (dev/test/prod) across three live products; the output should be the same with or without happypack otherwise it's a glaring bug and we'll fix it.