Mastering Babel: Optimize JavaScript Transpilation and Reduce Bundle Size

When thinking of Babel, common keywords include language features, TC39, patches, extensions, ecosystem, and performance concerns.

Babel’s primary goal is to let developers use ECMAScript proposal features early; it is also used for patching, code‑mod transformations, file‑type detection, enforcing constraints, and magic features such as auto CSS modules.

The language features are provided by Babel’s official plugins, categorized into stages from 0 to 3. preset‑env excludes features below Stage 3, so the typical setup combines preset‑env with manually selected lower‑stage plugins.

Features fall into two groups: compile‑time transformations (e.g., [1, 2, 3].map(n => n + 1) becomes [1, 2, 3].map(function (n) { return n + 1; })) and polyfill patches (e.g., Array.prototype.includes for browsers lacking .includes). Some features require both approaches.

Compilation generates helper code; for example, class syntax introduces helpers like inherits, setPrototypeOf, createSuper, getPrototypeOf, and classCallCheck. Because Babel compiles per file, duplicate helpers can bloat output. The common solution is plugin‑transform‑runtime together with @babel/runtime, which centralizes these helpers.

Note: plugin‑transform‑runtime should not be paired with corejs for polyfills, whether in a project or a component. The reason is left as an exercise for the reader.

Babel offers two polyfill strategies via targets and preset‑env ’s useBuiltIns option: entry (replaces a core‑js import with a full feature list) and usage (injects only the features actually used).

Module type conversion (e.g., ESM to CJS or SystemJS) should be handled by bundlers, not Babel. Consequently, the modules option in preset‑env is effectively useless and should always be set to false.

Performance is a major concern: slow Babel processing affects developer productivity and overall engineering solutions. Avoiding Babel on node_modules eliminates many issues, such as large bundle sizes, IE11 compatibility problems from untranspiled dependencies, and the need for separate TypeScript compilation for component publishing. This performance gap creates opportunities for alternatives like SWC.

Although Babel’s ecosystem is rich, useful third‑party plugins are scarce. In the author’s current Umi setup, the only practical plugins are import, macros, svgr‑webpack, and named‑asset‑import. Many tasks Babel can perform are more appropriately handled at the bundler layer, which operates on the entire output rather than just project source files.