Glossary / Transpilation

Transpilation

Transpilation transforms source code into a different source form while preserving intended behavior, commonly converting newer JavaScript syntax or TypeScript into code accepted by target runtimes. It is distinct from bundling, type checking, and polyfilling, though build pipelines often combine them.

Syntax transformation vs runtime APIs

A transpiler can rewrite syntax such as optional chaining or class fields, but syntax rewriting cannot by itself provide a missing runtime API such as Array.prototype.flatMap, Promise, or Intl. Those require a polyfill or a different implementation. Output depends on target configuration and assumptions about built-in support.

TypeScript compilation can erase type annotations and emit JavaScript; Babel can transform syntax and plugins; bundlers may integrate esbuild, SWC, or other transforms. Transform order matters for decorators, JSX, class fields, and source maps. TypeScript's target controls emitted syntax, while lib describes available type declarations and does not install runtime polyfills.

Engineering guidance

Set targets from supported browser/Node matrices, not habit. Avoid transpiling syntax every target already supports unless needed for consistency. Test the emitted artifact in the oldest supported runtime and ensure required APIs exist. Keep source maps accurate across chained transforms, and pin plugin versions because semantics can evolve.

Interview questions

  1. Does transpilation add missing APIs? Not automatically; syntax transforms differ from polyfills.
  2. What does TypeScript target control? JavaScript syntax level emitted, not runtime API availability.
  3. Is transpilation bundling? No; it transforms source, while bundling packages a module graph, though tools combine them.
  4. Why test emitted code? Source may run only because a dev tool transforms it differently than production.
  5. What guides target choice? A documented runtime support matrix and measured compatibility needs.

References