Consider not parsing/stringifying cached transform

[thymikee]

Babel Loader Version: current (8.0.0-beta.0) but I believe it stays since beginning (or at least 6.x)

Current behavior: When cacheDirectory option is set, babel-loader before/after zipping (https://github.com/babel/babel-loader/issues/571) performs JSON.stringify/JSON.parse to store the { code, map, metadata } from babel.transform() call

Expected/desired behavior: We need to store just 2 types of data: code and map. BTW, what are valid cases for using Babel's metadata field? We could still provide it, but in my brief testing the object was always empty, so I got a bit confused here.

When using inline source maps with e.g. devtool: 'eval' (which happen to be used while development, which in my experience is the environment where cacheDirectory is set usually), we end up with map bundled with transform, so we only need to store code for most cases. The other case is when source map is another file and we'll cover that too.

So for both cases we're able to get rid of JSON.stringify/JSON.parse (and we want to, as these are pretty slow).

• inline source maps: we end up with just one cache file per source being written to disk
• non-inline source maps: we end up with 2 cache files per source being written to disk (I'd like not to mix these two into one file, but that's also possible)

Even when using non-inline source maps, the benefit of not-calling JSON.stringify/JSON.parse should outrun the drawback of having 2x fs calls.

Would you be interested in accepting a PR changing current behavior?

Combined with https://github.com/babel/babel-loader/issues/571 this should result in some nice perf wins.

[edmorley]

Hi! In #571 you mention you have a local branch for this change? If you had a chance to push it up somewhere, I'd be curious to see the impact on performance.. :-)

[thymikee]

Lol, I removed the whole babel repo while doing local chores 🤦‍♂️. But the perf improvements were minimal and I was not super happy.