Glossary / Source maps

Source maps

A source map describes how positions in generated JavaScript, CSS, or bundled output correspond to original source files. It lets debuggers and error-reporting systems show authored code and meaningful locations even after bundling, transpilation, or minification.

Map contents and chaining

A map typically contains generated-to-original mappings, source file names, optional embedded sourcesContent, and names. Tools can consume upstream maps and emit a composed map across transforms; if any step drops or misapplies mappings, final locations become inaccurate. The sourceMappingURL comment or HTTP headers can point to a map, and dev servers may serve maps differently from production.

Maps are version-sensitive: they must correspond to the exact deployed artifact. A stale map can produce convincing but wrong stack traces. Inline maps increase bundle size and may expose source. Hidden or private maps can be uploaded to an error service while omitted from public routes, depending on tool configuration.

Engineering guidance

Test a known production stack trace end to end. Preserve source maps through every transform, record artifact/build IDs, and restrict access if maps contain proprietary code. Decide whether sourcesContent is included. Ensure stack-trace symbolication uses the same release identifier and source revision as the deployed files.

Interview questions

  1. What does a source map do? Maps generated positions to original source locations.
  2. Why can a valid map still give wrong results? It may belong to a different generated artifact or be composed incorrectly.
  3. What is sourcesContent? Optional original file contents embedded in the map.
  4. Why not always publish maps publicly? They may expose source and internal paths.
  5. How verify a production map? Symbolicate a known deployed stack trace using the exact artifact/release.

References