Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Preserve object identity when loading config, for improved future caching. #6326
This change does essentially nothing on its own, but it opens up a bunch of options for us in the future. By preserving the object identity of as much of our config as we can, we can better cache processing around those configs.
In the future
The simplest case for this is that with this we can validate a config file and cache it by just doing
We'll also be able to apply that caching for plugins and presets, so if you're babelrc is
currently in Babel 6, the preset function for
And we have the opposite problem in plugins currently. Plugins are always cached for performance, but this means we're locked with the plugin API as
I have this caching all done on a branch, and it improves the time to go from the name of the file to compile, to a fully verified config object and an array of plugins by ~2-3x, while allowing plugins to have access to options up front, which is a huge win in my mind.
In this PR
The most complex part of this PR is that I've implemented identity preservation rules for arguments passed to Babel too. Babel's top-level options object passed in programmatically is something that is commonly either mutated often, or passed as a fresh object. This means it's essentially impossible for us to do the caching I mentioned above for plugins/presets/whatever.
One approach would be to freeze every options object passed to Babel, so we could know the user hasn't gone and mutated it between calls, but the DX on that would be a pain for everyone.
To try to strike a middle ground, in this PR I've approached the issue by caching individual properties of the programmatic options object by their identity instead. So for
This means that babel won't be able to cache the option validation I mentioned above for the programmatic options, but it will be able to do it for the plugins, presets, and anything nested under the
I think it's a solid compromise, but I'm curious for feedback.
@hzoo No it wasn't cached before, it's more that we will cache plugins and presets (once I add caching), so something like
would not use react on the second call, because the
I think that's fine as an edge case though.
If they did
though, so it was a whole new array, it'd work.