We are happy to report that we recently added support for source maps in RootCause. This means you can now see the original file in which an error happened, and not have to look through huge compressed / minified files like index.min.js.
The benefit of source maps
Let’s first look at a regular vanilla stack trace when having a single minified application js file without source maps. As you can see below we only get references to positions in one line in one huge file:
Now let’s take a look at how the stack looks when using a source map in our tool chain:
As you can see, the real file, line number and column number are all displayed which makes it so much easier to navigate the code. By clicking a stack frame line the relevant source code is displayed.
Get started with source maps
In order to get source maps working, you have to ensure that your tool chain generates a proper source map file and that a reference to this source map file is appended to your minified javascript file.
For example, if you are using UglifyJS and you have three javascript files which you want to combine into a single minified index.min.js, use this command:
uglifyjs script1.js script2.js script3.js -o index.min.js --source-map includeSources,url=index.min.js.map
Note the “includeSources,url” parameters, which are required to properly extract the original source code from the source map file. Other tools such as Babel, WebPack or Gulp have their own ways of generating a source map.
When an error is triggered and sent to the RootCause server, we process the source map immediately. This means we always show you exactly the same source code which was on your server at the moment when the error occurred, even if you made changes to your code and redeployed.
We hope you’ll find this feature as useful as we do, happy debugging!
Leave a Reply