#1798 caused drastic regressions in our ability to invalidate the precompilation cache. This was intentional, as we wanted to upgrade to newer Babel 7 betas.
There's a few TODO comments in lib/babel-pipeline.js with pointers on how to improve our cache invalidation:
|
// TODO: Check for `partialTestConfig.config` and include a hash of the file |
|
// TODO: Take resolved plugin and preset files and compute package hashes for |
With regards to plugins & presets, we should figure out what package the resolved plugin / preset is from, and then use package-hash to compute a hash. If the plugin / preset is a file in the current project (and not a dependency) we should just hash the file. The same if it's from outside of the current project.
We're now resolving Babel options for every file that's being compiled. We should therefore have a lookup of resolved plugins / presets and config files to previously computed hashes.
package-hash has an asynchronous mode which we could use, though we'd have to change the pipeline to be asynchronous itself, so that'd be a bit more work.
userOptions may come from an ava.config.js file (at least when #1761 lands). Consequently they may include non-serializable values. Perhaps we should serialize it using Concordance before taking the hash.
#1798 caused drastic regressions in our ability to invalidate the precompilation cache. This was intentional, as we wanted to upgrade to newer Babel 7 betas.
There's a few
TODOcomments inlib/babel-pipeline.jswith pointers on how to improve our cache invalidation:ava/lib/babel-pipeline.js
Line 134 in a5de369
ava/lib/babel-pipeline.js
Line 111 in a5de369
With regards to plugins & presets, we should figure out what package the resolved plugin / preset is from, and then use
package-hashto compute a hash. If the plugin / preset is a file in the current project (and not a dependency) we should just hash the file. The same if it's from outside of the current project.We're now resolving Babel options for every file that's being compiled. We should therefore have a lookup of resolved plugins / presets and config files to previously computed hashes.
package-hashhas an asynchronous mode which we could use, though we'd have to change the pipeline to be asynchronous itself, so that'd be a bit more work.userOptionsmay come from anava.config.jsfile (at least when #1761 lands). Consequently they may include non-serializable values. Perhaps we should serialize it using Concordance before taking the hash.