Skip to Content
In my blog A debugging issue caused by source code mapping I introduced an issue which makes me confused and finally found out that it is working as designed based on JavaScript source code map supported in Chrome development tool. Still some of my doubt is not clarified at that time. Recently I make further research with help from my colleague Wang Cong and I share my learning with this blog.
I build a simple UI5 application to explore source code map functionality.
I just draw a Button in XML view and display a Message Toast once it is pressed.
Here below are my XML view definition and controller implementation.
Switch on JavaScript source code map in Chrome development tool setting:
Then we can observe lots of library files with DEBUG version (.dbg.js) are displayed in Chrome development tool, nevertheless you could NEVER observe that they are loaded in Chrome development tool Network tab. So here the question is: where do these .dbg.js files come from?
When you switch off JavaScript source code map in Chrome development tool, the library files with DEBUG version also disappear in Chrome development tool. Compare the difference:
Since we are discussing about source code map in this blog, we know such magic is done by source code map mechanisum. How does it work under the hood?

How to locate sap-ui-core.js.map in your local laptop

Click sap-ui-core.js in Chrome development tool, in the last line 1875 there is a line:
//# sourceMappingURL=sap-ui-core.js.map
The name of this file gives a hint that it provides the mapping detail between each code position in original, unpacked source code file and the position in the generated code file.
However, I can NEVER observe that the sap-ui-core.js.map is loaded via network tab. Why?
Type “chrome://net-internals/#events” in Chrome and I realized that there is indeed a url request sent for sap-ui-core.js.map, but served by disk cache as displayed below.
Use “chrome://cache” to review the local cache of your Chrome application. In my laptop I successfully found the cache entry for sap-ui-core.js.map.
Click this hyperlink to review cache detail. In Chrome we can just see the cache header information, the content is displayed in HEX format.
Then I download the tool, Cache viewer for Google Chrome Web browser, to view and export Chrome cache to a local file.
finally I can open sap-ui-core.js.map in my local laptop.

Go through sap-ui-core.js.map

It is recommended to read this blog Introduction to JavaScript Source Maps to get some basic understanding about JavaScript source code map.
The content of sap-ui-core.js.map looks as below:
  • version: 3
The building block of JavaScript source code map file is defined in Source Map Revision Proposal document. In my example sap-ui-core.js.map uses the 3rd version which could be found from here.
  • sources:
the JavaScript source files specified in this array will be used to generate a combined file named sap-ui-core.js.
names: this array includes the name of all variables and their properties used in the source files.
Here below are some example of variables used in original source file Device-dbg.js and their corresponding records in names array in sap-ui-core.js.map.
  • mappings:
the concrete mapping information are maintained here. The mapping is organized based on generated code with line level, separated by semicolon.
The generated sap-ui-core.js has 1874 lines so for sure in sap-ui-core.js.map there are totally 1874 occurances of “;”, each one responsible for maintaining one line’s mapping information of sap-ui-core.js.
What’s the meaning of such AAsBA, EAAG? Before we touch them, another question is how to generate a map file?

How to generate map file

There are several approaches to generate map file. One option is Google Closure compiler. Suppose I would like to generate a packed file from my controller file App.controller.js.
Download compile.jar from this url and generate packed file named script-min.js with mapping file named script-min.js.map.
java -jar compile.jar --js App.controller.js --create_source_map ./script-min.js.map --source_map_format=V3 --js_output_file script-min.js
There is only one line in generated script-min.js:
Generated source code map file script-min.js.map:
You can use vlq.js to convert those encoded value:
execution output as below. You can observe that each encoded string ( called segment in Source code revision proposal 3 ) consists of FOUR or FIVE digits of characters.
The below explanation are copied from Source code revision proposal document.
The fields in each segment are:
1. The zero-based starting column of the line in the generated code that the segment represents. If this is the first field of the first segment, or the first segment following a new generated line (“;”), then this field holds the whole base 64 VLQ. Otherwise, this field contains a base 64 VLQ that is relative to the previous occurrence of this field.
2. An zero-based index into the “sources” list.
3. Zero-based starting line in the original source represented. This field is a base 64 VLQ relative to the previous occurrence of this field, unless this is the first occurrence of this field.
4. Zero-based starting column of the line in the source represented. This field is a base 64 VLQ relative to the previous occurrence of this field, unless this is the first occurrence of this field.
5. If present, the zero-based index into the “names” list associated with this segment.
The definition perfectly explains why there are some negative integers in the above screenshot.
So far I have explained the most basic stuff regarding JavaScript source code map, if you would like to manually construct a original source file based on generated file + source code map file in your mind, you can refer to this blog in Microsoft community: Source Maps under the hood – VLQ, Base64 and Yoda.
To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply