Unbundle your JavaScript with Source Maps in Chrome DevTools
Most of today’s websites use optimized, compiled, minified and obfuscated javascript and CSS. Examining this stuff here has some severely limited utility, which is why when developing we rely on sourcemaps. We’ll set up a webpack workflow that uses sourcemaps to show you how they can help your debugging!
[00:00] It's pretty cool how using today's tooling we can write really relatively little code in order to get some pretty powerful results. Looking at our little sample application here, this is a React application. I've got my index file, which is rendering what I'm calling my greeter. That's like saying, "Hello Egghead," and allowing me to change my name. Then it embeds this kitten.
[00:22] I've got 40 lines of code here. This is our complete application takes about a 100 lines of code to build. That's not very much code. That should be pretty easy to debug that when it's running.
[00:36] If we for instance click this and we want to take a look at where this particular console.log statement came from, we can click the source. That pulls us over into our sources tab into bundle.js. It takes us to line, whoa, 19,710 to get to that particular console.log statement. What happened? How did we go from 100 lines of code to 19,000?
[01:03] This is what we call in professional terms dependency hell. Not only do we have our code, we've pulled in React, we've pulled in Axios, we've pulled in all of their different dependencies. The thing that enables these modern frameworks to be so powerful is that they write a lot of code that you don't have to write. But that code still has to get written. That code still has to be a part of what gets sent to the browser.
[01:33] The browser needs more than just our 100 lines in order to function. By using modern compilers, a lot of that stuff just gets bundled into a single optimized bundle.js file. That's what the browser sees. This can be really tricky to debug.
[01:52] Fortunately there's a great technique that's available. Depending on your build tool, this will work a little bit differently, but the name for this is source mapping. If we go over here and we look at our web pack config, we can actually provide a field here in the web pack configuration called dev tool. It's got a variety of these available. Let's just use this one for now.
[02:14] This is going to create a source map for us so that when our application builds, it's going to provide a mapping from the giant bundle.js file to our elegant, small source files. Now that I've got that turned on, if I refresh my page, I'm going to see that I've actually got one more source here in my list of sources. This is stuff being provided by web pack itself. Web pack is now allowing me to look directly at my source files.
[02:45] Here's that very nice, short index page. Here's our greeter. Here's our kitten. This looks just like what we have in our sources. This is great because if I then click get name from server, now instead of sending me to line 19,710 in bundle.js instead it's sending me to line 18 of greeter.js.
[03:07] I click that, and you can see the source map allowed the texting here to get split up and organized and represented here in a much smaller unit so that it's easy for me to step through and understand where did this come from? What's calling it? By source mapping your JavaScript, you can also source map your CSS if you're using something like Less or Sass.
[03:31] Including these files is really powerful for debugging. Chrome's sources panel plays very nicely with them.
There was some change in webpack recently that made it necessary, but I'm not 100% clear on the details. Webpack for me is usually a matter of getting it to work once and then forgetting about it :P
But maybe it'd be worth looking into that, I'm curious too.
What's the purpose of # symbol before 'eval-source-map'?