Explain sourcemaps

jochemstoel profile image Jochem Stoel ・1 min read

Please define sourcemap, describe in your own words the purpose/value of sourcemaps, demonstrate this with a real world example and elaborate further where-ever you see fit. Thank you.


markdown guide

When we write the code (often JavaScript in this case), we create a source. The source code looks the way we first input it.

But when we serve the code, often we don't want to send the "source" code to the end user, we send a compressed version. Things like "UglifyJS" turn the code we write, changing all the variables into single letter vars and remove all the whitespace in the file. What we end up is code that behaves the same way but is shipped to the end use in fewer bytes. This means faster webpages. Overall we try to send as little data as possible if we can help it.

mishoo / UglifyJS

JavaScript parser / mangler / compressor / beautifier library for NodeJS

UglifyJS – a JavaScript parser/compressor/beautifier

NEW: UglifyJS2

I started working on UglifyJS’s successor, version 2. It’s almost a full rewrite (except for the parser which is heavily modified, everything else starts from scratch). I’ve detailed my reasons in the README, see the project page.


Version 1 will continue to be maintained for fixing show-stopper bugs, but no new features should be expected.

UglifyJS — a JavaScript parser/compressor/beautifier

This package implements a general-purpose JavaScript parser/compressor/beautifier toolkit. It is developed on NodeJS, but it should work on any JavaScript platform supporting the CommonJS module system (and if your platform of choice doesn’t support CommonJS, you can easily implement it, or discard the exports.* lines from UglifyJS sources).

The tokenizer/parser generates an abstract syntax tree from JS code. You can then traverse the AST to learn more about the code, or do various manipulations on it. This part is implemented in…

We also use transpilers such babelJS, which let us write more "modern" javascript features and compile them into code which works across all browsers, even the older ones.

babel / babel

:tropical_fish: Babel is a compiler for writing next generation JavaScript.


The compiler for writing next generation JavaScript

Travis Status CircleCI Status Coverage Status Slack Status npm Downloads

Supporting Babel

Backers on Open Collective Sponsors on Open Collective Business Strategy Status

Babel is a community-driven project used by many companies and projects, and is maintained by a group of volunteers. If you'd like to help support the future of the project, please consider:

  • Giving developer time on the project. (Message us on Twitter or Slack for guidance!)
  • Giving funds by becoming a sponsor (see below)!

Open Collective Sponsors

Become a sponsor and get your logo on our README on Github with a link to your site. [Become a sponsor]

Patreon Sponsors

Become a sponsor and get your logo on our README on Github with a link to your site. [Become a sponsor]


Mike Sherov


Babel is a tool that helps you write code in the latest version of JavaScript. When your supported environments don't support certain features natively, Babel will help you compile those features…

But what happens if we ever want to go back in the other direction, perhaps to debug? Now we have to map the compressed or compiled code back to the source. It's a series of instructions that can help turn things back into source code if we need it. If a sourcemap is created, there's probably an associated tool that knows how to interpret the sourcemap.

I think that's the gist, if anyone thinks I made a mistake, let me know!


Hi ben! I'm slightly confused: what kind of situation is that where you need to debug and you only have an uglified version of your code, and not the original source?


You'll have an issue on a browser that doesn't support your code as-is (spread syntax, for example).

The code in the debugger is not your code - it's the foreign code. You can have your own code, but you have to step through this stripped-down code.

Unless your source is mapped, you won't know what code you're actually stepping through.


It's when something good wrong on production sure, but your code has been minified to one line, very hard to figure out what's going on when error is on Line 1.

Not sure if chrome's new pretty print option for source files will fix that tho now?

I’m not sure the whole landscape but I’m pretty sure there are tools that allow deciphering prod bugs in this way, and I feel like there are also uses for this mapping in CSS -> SASS land.

But not really my expertise, perhaps someone else will jump in and give a better explanation.

I tried to reply to this comments parent but can only see some text that says “thread” where the reply should be so I’m replying here.

Chromes pretty print is still not enough. I’m unsure if the latest dev tools could point to the correct line or not, but it would still likely not matter.

If you pretty print a single line compiled file, there will still be multiple things wrong while debugging such as

  • what was the original file called (and the line it) before the file went through a module bundler or concatenation.
  • What was the name of of the variable or function? Uglify probably reduced down to only 1 or 2 letters.
  • What was the syntax of the original code? Transpires like Babel or typescript concert new syntax into old syntax. Play around on the Babel transformer a bit to see what type of code actually gets emitted. babeljs.io/repl/ some transforms like a sync/await look totally foreign when transpiled.

Loud and clear. Thanks, Ben!