webpack-contrib/cache-loader

cache-loader VS happypack

superpig opened this issue ยท 9 comments

what's the difference between cache-loader and happypack?

Did it have some data test between cache-loader and happypack ? Or can I use both of them ?

I'm definitely not sokra, but one difference is that happypack is parallelized. This looks to be a much smaller configuration for easy perf wins.

Keep in mind that babel-loader (which is likely processing the most files in your code) has a built in cache as well.

@gdborton cache-loader != babel-loader (cache). Why?

What contain cache-loader in cache (https://github.com/webpack-contrib/cache-loader/blob/master/src/index.js#L36)

  1. remainingRequest
/path/to/node_modules/babel-loader/lib/index.js??ref--0-1!/path/to/src/containers/app/app.js
  1. dependencies
[ { path: '/path/to/src/containers/app/app.js',
    mtime: 1493382032000 },
  { path: '/path/to/node_modules/cache-loader/dist/cjs.js',
    mtime: 1493198456000 },
  { path: 'path/to/node_modules/babel-loader/lib/index.js',
    mtime: 1493381646000 } ]
  1. contextDependencies (It makes no sense with only babel-loader but makes sense if you use loaders which add context dependencies before babel-loader, let's see who it do https://github.com/webpack-contrib/cache-loader/blob/master/src/index.js#L36)
  2. result - transpile code and options for cache-loader
[ '\'use strict\';\n\nconsole.log(\'Cache here\');', null ] // instead `null` your can have options here for `cache-loader` 

Hm, what does it make sense to use together cache-loader and babel-loader (for most use case, where one babel-loader for scripts)?

  1. Yes, if your don't use cacheDirectory option for babel-loader (cache-loader caching all transpile code and other own stuff see above).
  2. Rather Yes Than No, if your use cacheDirectory option for babel-loader, pitch loader (https://webpack.github.io/docs/loaders.html#pitching-loader) some faster then standard (sync/async) loader.

If you have any comments I'll be happy to hear, if you want to know how to use it together style-loader/css-loader just put +1.

As I read about happypack the creator said:

I just assumed webpack 2 has a higher overhead and never investigated since I don't have much time for this anymore.

Here is the thread: amireh/happypack#144
And if you read their issues you will see there's more problems with webpack 2.

So I think better use cache-loader since it's from webpack creators and it will be maintained as well.

P.S. I tested cache-loader with babel-loader so for me the rebuild time was the same, no difference if I use babel-loader with cacheDirectory or cache-loader without cacheDirectory or with cacheDirectory enabled.

FYI, cache-loader decreased our build times from 100 seconds to 33 seconds @ trivago.

Edit: I'll put more context here. We use babel-loader, some combination of css, sass, style, file, raw loaders for some static assets, custom loaders for loading in-house templating engines etc. I've tested each of them one by one. cache-loader helps for all of them. Number of seconds depends on how much work loaders before cache-loader do. I've tested this on a Macbook (in case SSD and OS makes a difference). We have thousands of JS modules, using cache-loader infront of babel-loader decreases build time by 50 seconds.

So I think better use cache-loader since it's from webpack creators and it will be maintained as well.

That sums it up pretty well :) Feel free to reopen if still any questions

Not sure why there is a "vs."? It looks like I can use them together and get ~3s wins on re-runs. Or are there any caveats I don't know?

@donaldpipowitch Well as far as I know they both do the same thing = caching of built files. The main difference would be happy adds parallel compilation support to webpack, but to be honest I never noticed a difference on my other cores while running it. In a test bench I did for my project it even took longer for the initial build to complete.

I'm not sure using both of them is wise as they might start fighting each other...