 Today, we are talking about maps, but not this map, it's the source maps. In this episode, we will explore the basics of source map and how it can help make debugging easier. Let's dive in. This is our web application. We have a HTML page with a header, a greeting button, and an empty paragraph. It links to a CSS and a JavaScript file. In the CSS file, we style the header color. Over to our JavaScript, we have a button click event to generate a random number and a greeting message. In the World Without Source Map, what you view is what you see. You can host the application as is. In the browser, you can see there are three files loaded exactly. Click the button. In the console, we can see DevTools point out the exact line of code that locks the message. We can even set the breakpoint and start the debugging session. However, this might not be the code you ship to production. Moreover, your development process may involve using CSS preprocessors, JavaScript frameworks, or TypeScript, which require a build process to transpile your code into the standard HTML, JavaScript, and CSS. To further optimize performance, it is common practice to minify and aglify these files, reducing their size and making them more efficient for the web. It's a lot of work. However, usually, your build tools like Weed, Webpack, or Parcel will take care of these processes. Here is the same demo built with TypeScript and SCSS. These are the files generated after the build process. Let's focus on the JavaScript file and compare it to the original TypeScript. Notice that the code has been compressed into a single line. The number variable being renamed to an even shorter name and grid being embedded directly in the final output. While this optimization can improve performance, it also makes debugging more challenging. Imagine encountering an error in this compressed code with everything on a single line and shorter variable's names, it can be really difficult to pinpoint the source of the issue. That's what SourceMap is for. It maps your compile code back to the original code. SourceMap are files with names ending in .map. They can be generated by most build tools, with some tools including them by default while others may need additional configuration to produce them. Let's take a quick look at the JavaScript SourceMap. Here is the interesting bit. The sources feel whole a list of original sources used by the mappings entry. In our case, there's only one file, but it can be more. The mappings feel is where the real magic occurs. It tells us how to map lines and locations in the compile file to the original files. The mappings feel use vlq-based64 encoder string. Sounds complicated? Fear not. I can show you a quick way to visualize the mapping. Here, I'm using a SourceMap visualizer that was built by Tobias and Paul Irish. To get started, I import the minified file along with its source map to the site. The visualizer color codes each line. Let's focus on the decoded source map. Each entry has two parts. On the left, you will see the position of the corresponding code in the generated file. And on the right, you will see the exact line and column of the original code. For example, if you hover over the cones, you will see that its mapping starts from the position 65 in the generated file and is linked to the second line, position 2 of the original source. Take note that the line number 3 is not mapped at all because it was removed during the build. Apart from that, SourceMap supports extension. This extension starts with the X underscore naming convention. For example, there is an X Google Acknowledge extension field. It is a common field proposed by Chrome DevTools. If your build tools or frameworks support this extension, DevTools will use it to improve your stack trace. Here is how it works. For example, this source map contains multiple sources. Some of these are third-party files, which may not be relevant for debugging. JavaScript frameworks and build tools can use the X Google Acknowledge field to indicate that these files should be ignored for debugging. DevTools will read these fields and use them to help you to pinpoint your issues quicker. Look at this stack trace. DevTools automatically hides all the third-party frames in the stack trace and show you only those frames that are relevant to your code. While you can still view the hidden frames by expanding them, they are typically just noise and can be ignored. The good news is, frameworks like Angular and Nux already configure X Google Acknowledge in their source map. You get the stack trace improvements for free. Build tools like rollup and vid also offer settings to configure it. If you are a framework or library maintainer, it is essential to understand how to implement these settings to improve your user debugging experience. Go to this link to find out more. Alright, we learned a lot about how source maps works today. Find out more in our documentation or the spec. Stay tuned for our next episode. We will dive deeper into how DevTools uses source maps to enhance your debugging experience. Good luck mapping. See you for the next DevTools tips. Ciao!