cache-loader VS happypack about cache-loader HOT 9 CLOSED

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

• cache-loader caching information which need to speedup webpack build (see https://github.com/webpack-contrib/cache-loader/blob/master/src/index.js#L25, including transpile code from babel-loader)
• babel-loader with cache only caching transpile code (https://github.com/babel/babel-loader/blob/master/src/index.js#L156)

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

2. 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 } ]

3. 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)
4. 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.

from cache-loader.

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.

from cache-loader.

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.

from cache-loader.

And the existing https://github.com/jsdf/cached-loader.

from cache-loader.

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

from cache-loader.

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.

from cache-loader.

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

from cache-loader.

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?

from cache-loader.

@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...

from cache-loader.