The way we load plugins and expose config right now is confusing (see OptionManager#init) and leads to lots of complexities. babel-register and babel-loader both implement their own logic to decide if the value they have in their cache is the equivalent result that they'd get by running Babel. We also saw #3564 where Ava could potentially be faster by not loading as many pieces of pieces of babel up front when it hasn't been configured and there are no .babelrc files. We could encapsulate that.

I'm opening this as a RFC to get feedback. I've been thinking that this might be a good thing to move into the core. Perhaps along the lines of

const {
  // The compiled output
  code,
  // The output sourcemap
  map,

  // An opaque string cached for this file and passed in on the next call.
  cacheData
} = babel.transform(someCode, {
  filename: 'someFilename.js',
  // enable cache data calculation
  cache: true,

  // some opaque data representing the cacheable data for this file 
  // from the last time it was compiled.
  cacheData: thePreviousCallCacheData,
});

where it would be up to the caller to store the cache data and pass it back in next time the file is processed. We could also have a separate flag to automatically read and write from a cache file somewhere.

By moving this into the core, it would let us intelligently bail out early if we know a file passed to Babel has no plugins applied to it, where right now users of babel are forced to cache without taking .babelrc into account, or would have to parse it themselves. As we talk about adding .babelrc.js that gets even more complex.

In a perfect world, we'd expand the plugin framework to allow plugins to indicate caching metadata, so if a plugin bases its transforms off of NODE_ENV or something, a plugin could indicate this, but if we get the base API in core right, we could add that at a later time.

This also means that we could version the cache properly, like plugins could include their version numbers in caching data, so if a user upgrades a plugin, the cache would invalidate properly, which does not happen right now.

Webpack does this at the moment AFAIK with their updateHash function allowing different pieces to update the overall hash value as data is processed. That invalidation issue is also one of the primary reasons I recommend against using babel-node and babel-register right now.