Webpack & TypeScript Setup #6 - Source Maps

Key Takeaways

All right, then, gang. So, sometimes when you're building an application and you're building to the bundle, after you've done that, you might like to work in the browser to debug your code and test your code, right? Now, at the minute, if we were to build our code and then preview it with the built bundle, we won't be able to see our source files. And this is not using the Webpack dev server. This is just serving up this stuff right here in the public folder after it's been built using a different local server. Now, to demonstrate this, I'm using a package called live server, which you can install by searching for live server right here in the packages file. And what that enables us to do is go to any HTML file, or right click it, and open with live server. So, this is no longer using the Webpack dev server, just a local slimmed-down development server. So, if I inspect over here and go to sources, we can only see the bundle.js here. And if we wanted to debug this code, it's going to be very hard because it's all minimized here, and it's looking a bit of a mess, and it would be hard to debug. Now, let me just demonstrate this. If I go to the index.typescript file and just add in some kind of code, and all this is is declaring a constant called person of type any equal to an empty object. Now, imagine later in the code, we try to log to the console this person and use a method on it called speak, but we forget that we didn't initialize it. Well, this is going to cause some kind of error, right, in the code? So, if I save it and then build this by saying npm run build, it's going to rebuild that bundle and output it right here, okay? So, again, we're not using the Webpack dev server here, we've just built it, and we're serving this up using a different local development server. Now, if I go over here and go to console, we can see we get an error, and it says, "This.speak is not a function." And it gives us this bundle.js where the error is. Now, if we go to this, we can see right here that there is the error, but again, it's hard to read all of this code, and it would be nice if instead it directed us to our original source file. Now, in order to get that functionality and see our source files here with the error in so that we can debug in the browser, we have to use something known as source maps. Now, a source map creates a link between source files and compiled output files. So, in our case, it's going to establish a link between the bundle.js file right here and our TypeScript source files, so that then we can debug those directly in the browser. And when we get this error, it can direct us to the TypeScript file where the error was made, and we can see the original code. So, how do we use source maps in TypeScript and Webpack? Well, first of all, I'm going to go to the tsconfig, the TypeScript config, and I'm going to find the source maps. So, I'm going to scroll up to near the top where it says source map right here, and I'm going to change this to true. The next thing I'm going to do is go to the Webpack config file, and I'm going to paste in a line at the top of this object right here to say what kind of source maps we want. Now, I'm going to paste this in, and the property name is devtool, and we set it equal to this right here, eval source map. Now, there's many different property values we can place here for different kinds of source maps. And for production, you might just use source map instead of eval, but eval is quicker for development purposes. So, I'm going to save that, and now that we've done this and we've configured it for using source maps, we can go ahead and rebuild this saying npm run build. And if we go over here now and refresh this, we can see that now it points us to index.ts. So, it's linked our bundle with our original source files. And if we click this, we can see this error right here. And also, we can use this now to set different breakpoints in the TypeScript file. For example, I could set a breakpoint right here before we log any data. And if I go over here and type in a name, so for example, Mario, and we'll say the email is mario@thenet ninja.co.uk, and the age is 35. Submit. Now, we're going to pause at this breakpoint in the TypeScript file. That's really cool, right? So, we can work with our original TypeScript source now to debug our code. And we're not going to see that log until we have to step in or step over the function, and at which point we should see the log. At the minute, just an empty object because I think I made an edit to this. Yes, I did. I said return an empty object. This was just me playing around before. Instead, I'm going to return the values and try that again. So, come over here, and I'm going to refresh, enter in a name, and in fact, we need to rebuild first of all, so npm run build, and then come over here. And if we now enter in the name Mario and the email mario@thenet ninja.co.uk, the age is going to be 35. Let me go to index.ts and make sure we have that breakpoint right there. We do. Submit. Then step over the function, and we should see the log, which we do right here. So, my friends, that's one extra thing we can do with TypeScript and Webpack together, so that the development and debugging process is a little easier.