Description
Currently AVA resolves the Babel options itself. This gave us two benefits:
- Much better analysis of plugin / preset dependencies, and thus more accurate cache usage decisions
- Easier composition of AVA's built in Babel options and project configuration
- The ability to generate a single JS module which provided a fully realized configuration object
Back then the plan was to compile on-the-fly inside worker processes. Not having to resolve the configuration in each worker would have given a performance boost. We haven't gotten round to doing this yet, and I suspect it'd be the wrong approach for compiling TypeScript files.
Babel 7 is making Babel configuration files much more powerful. It's hard to keep up with those changes, especially if we want to create a fully realized configuration object. #1788 is a necessary bug fix which further negates the attempted performance improvements if *.js configuration files are used.
It's time to revisit this approach:
- We should take the dependency analysis from https://github.com/novemberborn/hullabaloo-config-manager/, utilizing some of the low-level APIs made available in Babel 7
- Any invalid inputs should be ignored
- If analysis fails, we should skip cache inspection. Perhaps we could log a warning
- I think we can get rid of https://github.com/avajs/caching-transform and implement a simpler version in AVA itself. Notably
require('babel')is no longer as slow as it used to be. As part of this we should be able to fix Handle compilation of files ignored by Babel #1667 - We should let Babel resolve its actual configuration
Composing AVA's options may be the trickiest thing to achieve when using just Babel. Note that we have an outstanding bug there, too: #1732.
For now I propose we switch to use pure Babel and forgo the dependency analysis. We may have to make it easier to clear the cache, though.
@avajs/core thoughts?