Add webpack's new cache loader

[ctrlplusb]

https://github.com/webpack-contrib/cache-loader

[diondirza]

never try it before, will it replace happy pack usage?

[ctrlplusb]

Possibly. It's a new kid on the block. We'll have to do some testing.

[strues]

I dont think it will be a 1:1 replacement for HappyPack. Main reason is HappyPack allows bundling to happen on different threads. Would be curious to see if running them in tandem gives a benefit.

[ctrlplusb]

Yeah, definitely not a 1:1 replacement, however if the benefits of happypack ontop of cache-loader are negligible I would vote in favour of removing happypack to reduce complexity.

[birkir]

The problem with HappyPack is that even though the workload is distributed between threads, the work itself is not separate enough to get the benefits I'd like.

The main webpack script gets a thread, and each of the loaders (new HappyPack()) get a thread (as I understand it). But almost all the work lies with the babel-loader, which only gets a single thread. Imagine if we could split that into multiple threads.

But its still faster than normal, both with and without the HappyPack cache.

[strues]

@birkir if you change the HappyPack plugin to look like this

import os from 'os';
import { execSync } from 'child_process';
import appRootDir from 'app-root-dir';

import HappyPack from 'happypack';

export function happyPackPlugin({ name, loaders }) {
   const compilerThreadPool = HappyPack.ThreadPool({
    size: os.cpus().length,
  });
  return new HappyPack({
    id: name,
    verbose: false,
    threadPool: compilerThreadPool,
    loaders,
  });
}

It will delegate the most resource intensive plugins, like babel-loader to use more threads than say sass-loader

[birkir]

Got it! Now seeing my CPU on full blast!