Question
Choosing esbuild vs Terser minification in Vite for latency‑sensitive builds
Dev Byte
0 reputation · 20 Feb 2023, 20:42 UTC
68.4K views1
Loading…
0 reputation · 20 Feb 2023, 20:42 UTC
The goal is to shorten Vite production build times without sacrificing the ability to run the output in browsers that require ES5‑compatible code.
Using build.minify: 'esbuild' leverages esbuild’s fast parsing and minification, but it may not apply the same level of TypeScript‑specific transforms or aggressive tree‑shaking that Terser provides, potentially affecting bundle size and source‑map fidelity. The safer default build.minify: 'terser' guarantees broad compatibility but increases build latency, which can be noticeable in large codebases or CI pipelines.
Which minifier delivers an acceptable bundle size for ES5 targets while preserving source maps? How does the build‑time difference affect CI workflows? Are there any known limitations of esbuild minification with the current Vite version that would require fallback to Terser?
35275 reputation · 20 Feb 2023, 23:47 UTC
For latency-sensitive CI builds that must output ES5-compatible code, use build.minify: 'esbuild' paired with build.target: 'es5' (or the lowest supported environment). This combination delivers Vite’s fastest production build while still producing browser-compatible output. If your bundle contains async/await or generators that must run in ES5 environments, add a legacy chunk via build rollupOptions.output.manualChunks and serve polyfills conditionally.
Terser does not provide TypeScript transforms or tree-shaking. Vite/Rollup handles both before minification. The minifier only affects compression, mangling, and dead-code removal within already-transpiled code. Therefore, ES5 compatibility is determined by build.target, not by the minifier choice.
vitejs
vitevite build twice with identical build.target and sourcemap: true—once with minify: 'esbuild', once with minify: 'terser'.dist/assets/*.js.gz or *.br sizes; measure wall clock time.Using esbuild reduces build minutes and runner costs, especially in parallel or matrix builds. Cache node_modules and the Vite pre-bundling step, but skip caching the minifier output if bundle size is critical—re-measure after each Vite or esbuild upgrade.
esbuild may refuse to lower certain syntax (e.g., optional chaining, nullish coalescing) to 'es5'. In those cases, Vite falls back to the original syntax in the output. You must either raise build.target or add a Babel/SWC legacy pipeline for those constructs.
Use comments to ask for clarification. Post a solution as an answer.
35,275 reputation · 21 Feb 2023, 05:44 UTC
When targeting ES5 in Vite, it is important to distinguish between transpilation and minification. While esbuild is significantly faster, it performs basic syntactic transformations. If your production requirements include aggressive dead-code removal or specific cleanup—such as stripping console.log statements via compress.drop_console—Terser remains the more robust choice, as esbuild does not honor these specific compression options.
To determine the impact on your specific codebase, you can run a comparative build test:
vite build --minify esbuild and vite build --minify terser.dist/assets/*.js file sizes to quantify the "compression gap."