 Previously, we talked about how SourceMap works. Now, it's time to explore how browsers use them to enhance your debugging experience. Let's go! SourceMaps are special. It only loads when you open DevTools. That makes a lot of sense, because it's better for performance and your users don't need SourceMaps. To check which SourceMaps are loaded, use the Command Shift P shortcut to open the Developer Resource tab and refresh the page. The tab listed all the SourceMaps, you can apply filters if the list goes too long. Great! Our project is built with HTML, TypeScript, and SCSS. Let's see how DevTools can help us pinpoint issues in our code. Click on the greeting button. In the console, you can see that DevTools actually maps it to TypeScript thanks to SourceMaps. Click on the link to open it in the sources panel. If you hover over the line at the bottom, DevTools will reveal the exact location from which this file was mapped. Clicking on it will take you directly to the generator file. DevTools automatically detects and formats your minified files for better readability. You can undo the format by clicking on the icon at the bottom. Now, what happens for minified files without SourceMaps? You can disable them in DevTools to try it out. Open the three-dot menu, select Run Command, and enter SourceMaps. You have options to disable JavaScript and CSS SourceMaps. Let's disable the JavaScript SourceMaps to see what happens. In the console, the log location now takes you to the compiled JavaScript file instead of the source file. Imagine you want to change the logic of the random number, you will need to manually map the code and variables in your mind. Let's re-enable the SourceMaps. Now, try setting a breakpoint at the console.log. DevTools will automatically open the original file and set the breakpoint there. Pretty cool, right? There are times where you have SourceMaps, but you want to keep it private, especially for your production code. In that case, when you are debugging that, you might want to attach the private SourceMaps manually. In this example, we hide the SourceMaps by default. There is no source URL in the generator code as well. Right-click on the page and select Add SourceMaps. Enter the URL of your private SourceMaps. If the URL is invalid, there will be warnings in the Developer Resources tab as well as the console. Try again with a valid URL. And there you go. The file is loaded successfully and your source is once again mapped. While SourceMaps is great, there are some gotchas as well. Sometimes, the debugging might not work as expected due to the limitations of the SourceMaps specification. Let's start a debugging session. When you hover over to the non-variable, you can preview its value. In fact, DevTools also supports in-line preview, and you can edit the value in the scope pane as well. Now, you might be wondering how about the wearable grid? Why is the line disabled and doesn't show any previews at all? It is because your build tools are smart. It detects that the grid variable can be removed and embedded value straight away in the message. Since the grid variable isn't mapped in the SourceMaps, DevTools won't be able to evaluate the value. This usually happens for production code, as the code is highly optimized. Development builds tend to have a more relaxed configuration. Another thing to keep in mind with SourceMaps is that build tools may have slight variation in how they handle the build due to the flexibility in the spec. The flexibility allows customization and could lead to a more efficient build. However, the flexibility of the spec can lead to confusion at times as well. For example, inspect the header. The CSS maps correctly to its original styles.scss. However, you might notice there are two CSS files in the page 3 instead of just one. Look at your project folder. You are pretty sure there is only one CSS file with that name and the content is minified CSS. What is happening here? Hmm, is that a bug in DevTools? Well, not really. DevTools get the information from the SourceMaps and display them accordingly. Open the source map. It has two sources. DevTools generate the map files based on the list. Take note that those files mapped by DevTools have an italic name. According to this line, DevTools maps and displays the unminified CSS. Another CSS file without italic name is the actual minified CSS file on this. Some build tools might just eliminate the intermediate level and map it straight from the minified CSS to SCSS. If that's the case, DevTools will only show you one CSS file which might be closer to your expectation. Well, the current source map spec doesn't actually dictate how mapping should be done. So, just take note of this in case you have the same confusion next time. Apart from that, you can turn on a setting in DevTools to view your original sources first if they are mapped. By default, DevTools mixes and shows all files together. You can group them by authored and deployed. In this case, the original files will show first in the authored section and the compile code shows in the deployed section. By the way, DevTools uses a source map extension called xGoogleAgnorList to improve your stack trace. Follow this link to learn more. I have a video explaining how it works as well. Alright, now you know everything about source map and DevTools. If you have more questions, feel free to ask in the comments below. That's all. See you in the next Tech Tool Tips. Ciao!