Babel-loader: Remove cacheDirectory in favor of using cache-loader

[hzoo]

Less to maintain, and it was inspired by babel-loader?

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

[michael-ciniawsky]

Does this have consensus amongst babel-loadermaintainers? I can do it 🙃

[DrewML]

Would certainly be nice to maintain less code 😸.

@michael-ciniawsky I suspect the only way we'd get consensus is after seeing traces. If you're interested, it would be awesome to see some comparative benchmarks between the 2 options.

Based on what we're using for the cache key currently, I think we'd need to expose something for people to use in their webpack config that would make it easy to get a cache key from this package. Too easy to get it wrong.

[alunny-stripe]

FYI on a large codebase (~3300 modules) at Stripe, we found babel-loader with caching to be significantly faster than cache-loader + babel-loader:

Warm-cache initial build:

# cache-loader + babel-loader
Time: 23586ms

# babel-loader with cache option
Time: 22481ms 

Rebuild after change to entry point

# cache-loader + babel-loader
Time: 9144ms

# babel-loader with cache option
Time: 4578ms 

(with cache-loader 1.2.2 and babel-loader 7.1.1)

[timm-aym]

I observed something similar:

Initial build time (we need to execute webpack twice due to react-loadable JSON generation):

no cache: 65s
cache-loader (2. full run): 41s
babel-loader with cache (2. full run): 33s

[loganfsmyth]

I think personally, Babel will always have more information about caching based on its own inputs and outputs, so I'd rather keep caching in babel-loader until babel/core itself has a caching framework like https://github.com/babel/babel/issues/8605