perf(gatsby): cache babel config items

[pieh]

On certain site:

Current:

success Building development bundle - 162.795s
success Building development bundle - 171.725s
success Building development bundle - 171.985s
success Building development bundle - 162.793s
success Building development bundle - 183.253s

With this change:

success Building development bundle - 113.453s
success Building development bundle - 110.612s
success Building development bundle - 112.168s
success Building development bundle - 112.159s
success Building development bundle - 110.889s

Just the packages/gatsby/src/utils/babel-loader-helpers.js change (biggest gain of all the caching added in this PR - at least for site I was benchmarking)

success Building development bundle - 118.803s
success Building development bundle - 123.173s
success Building development bundle - 119.359s
success Building development bundle - 120.030s
success Building development bundle - 118.143s

There might be more things to cache around this, but this was likely the most heavy thing that will yield biggest benefit

Explanation for changes:

babelLoader.custom(callback) runs callback function for every input file. babel.createConfigItem seems to instantiate new plugin/preset every time it's called. This seems to run https://github.com/babel/babel/blob/5b5b548036cde05b424d481c65c1c4a27c6eabc6/packages/babel-preset-env/src/normalize-options.js#L202-L263 separately for every input file even tho our options for @babel/preset-env don't change for given stage (@babel/preset-env is just example - it's similar for every babel plugin/preset, just this one seemed to be heaviest on site I was profiling).

Because babel@7 support nested .babelrc we can't not use babelLoader.custom (that would be breaking change/regression), but we can cache/memoize things we know don't change and avoid doing repetitive work.

The tricky part would be to memoize the partial config merging internals -

gatsby/packages/gatsby/src/utils/babel-loader-helpers.js

Lines 117 to 139 in 146b197

	const mergeConfigItemOptions = ({ items, itemToMerge, type, babel }) => {
	const index = _.findIndex(
	items,
	i => i.file.resolved === itemToMerge.file.resolved
	)
	// If this exist, merge the options, otherwise, add it to the array
	if (index !== -1) {
	items[index] = babel.createConfigItem(
	[
	itemToMerge.file.resolved,
	_.merge({}, items[index].options, itemToMerge.options),
	],
	{
	type,
	}
	)
	} else {
	items.push(itemToMerge)
	}
	return items
	}

So instead I opted to memoize one level higher -

gatsby/packages/gatsby/src/utils/babel-loader.js

Lines 64 to 98 in 146b197

	// If there is no filesystem babel config present, add our fallback
	// presets/plugins.
	if (!partialConfig.hasFilesystemConfig()) {
	options = {
	...options,
	plugins: requiredPlugins,
	presets: [...fallbackPresets, ...requiredPresets],
	}
	} else {
	// With a babelrc present, only add our required plugins/presets
	options = {
	...options,
	plugins: [...options.plugins, ...requiredPlugins],
	presets: [...options.presets, ...requiredPresets],
	}
	}
	// Merge in presets/plugins added from gatsby plugins.
	reduxPresets.forEach(preset => {
	options.presets = mergeConfigItemOptions({
	items: options.presets,
	itemToMerge: preset,
	type: `preset`,
	babel,
	})
	})
	reduxPlugins.forEach(plugin => {
	options.plugins = mergeConfigItemOptions({
	items: options.plugins,
	itemToMerge: plugin,
	type: `plugin`,
	babel,
	})
	})

Rationale behind this is that number of .babelrc files wouldn't be very high and even if we do some repetitive merging for each .babelrc file - at least we won't be doing this for every input file. On the site I was profiling there actually wasn't any extra .babelrc files and memoizing on that level (on top of memoizing prepareOptions) yielded extra 5s-10s gains.

There is always opportunity to figure out better memoizing setup to support cases of multiple .babelrc files better - but it's not clear to me how common using multiple of those configs is (maybe we should track this with telemetry and count "cache misses" per stage)

[ch27747]

[KyleAMathews]

This PR is similar #27974

[KyleAMathews]

Looks great! Like using webpack as a file watcher. Huge perf improvements 🙌