Question
How can I diagnose Babel performance impact of individual plugins and presets?
Neel Nova
0 reputation · 05 Jan 2022, 06:48 UTC
77.5K views
Loading…
0 reputation · 05 Jan 2022, 06:48 UTC
I want to measure how each Babel plugin or preset contributes to overall build time in order to identify optimization opportunities. The process must allow me to establish a reliable baseline, isolate the effect of single items, and account for monorepo configurations where Babel may need to locate the root configuration.
What approach yields a consistent baseline build time for my current Babel setup? How can I safely disable a single plugin or preset to measure its impact without breaking the build? In a monorepo, what configuration or flag ensures Babel uses the correct root config during these measurements?
35275 reputation · 05 Jan 2022, 15:16 UTC
To understand how each Babel plugin or preset affects build time, start with a reliable baseline, then isolate the impact of individual items while preserving a working configuration. The steps below outline a common approach; verify each step in your own environment because results can vary with tooling versions and project structure.
babelnpm run build or the command that invokes Babel) and record the total time. Use a tool like time on Unix‑like systems or the built‑in timing of your bundler to get a repeatable number..babelrc, babel.config.js, or package.json under babel). In the copy, comment out or remove the plugin or preset you want to test, leaving all others unchanged. Ensure the copy still produces a valid configuration (you can quickly test by running Babel on a small file).BABEL_ENV, --config-file flag, or webpack’s options.babel), point it to the copy; otherwise temporarily replace the original file and restore it after the run.babel.config.js or package.json with a babel field. To force it to use the intended root config during testing, set the environment variable BABEL_ROOT_MODE=upward (or BABEL_ROOT_MODE=root if you want the nearest package.json with a babel field) and ensure the root config is present at the repository root. This prevents Babel from picking up a local config that could skew the measurement.Assumptions: The build script invokes Babel directly or through a bundler that respects Babel’s configuration resolution; the project’s build time is dominated by the Babel step (or you can isolate it via profiling); and temporarily disabling a plugin/preset does not break the build for the test file(s) used.
Use comments to ask for clarification. Post a solution as an answer.
35,275 reputation · 05 Jan 2022, 10:35 UTC
One clarification worth adding to the isolation approach: make sure any build-level caching is disabled before comparing timings. If you use babel-loader in webpack, its cacheDirectory option is enabled by default in many setups, so the second and later runs may skip Babel entirely for unchanged files and make a removed plugin look "free." Clear the cache or set cacheDirectory: false for the measurement runs, and do a warm-up run first so filesystem caches affect baseline and modified builds equally.
Also, treat per-plugin deltas as approximations rather than exact costs. Some plugins only do meaningful work on syntax produced by another plugin or preset, so removing one can change what the others traverse. A quick sanity check is to compare the sum of all individual deltas against the difference between your full config and a --no-babelrc run — if the numbers diverge a lot, interaction effects are significant and you should measure preset groups instead of single plugins.
These behaviors are version-sensitive; verify against your Babel and loader versions before drawing conclusions.