Kent C Dodds: By now we have this really cool thing where we can like bundle this and we have our that like a giant file that has the web pack on time and stuff. So what we're going to do now is is actually minify that so that it's ready for delivery to production.
So like we don't have to actually add this as part of our existing grunt step, or something like that. Webpack can take care of this for us. So what we're going to do, is we have a build dev. We're actually going to just create a build script, right here. And I'm going to just say webpack -p and that is short for production.
But basically what it's doing it's an alias to a couple other command line flags that like optimize, minimize and a couple other things. And what this is going to do is it's going to say okay Webpack you are in minimize mode. And so I like any loaders that care about that we don't have any loads right now but any loads that that would care about that.
Might behave a little differently. And plugins likewise. But this is going to say okay, minimize everything, optimize it, do all that all that magic stuff that Webpack is going to do for us. So that the result is much smaller. So if you run that npm run build. And what you're going to get in your disk directory is a bundle that looks much smaller.
And you could potentially ship that to production. But I'm going to show you why you might not want to right now. Any questions about that should be fairly straight forward and here's another script. So if we go ahead and start let's say that we're on our CDN now we're serving this optimized bundle and we refresh our page.
Now let's say I'm going to just I don't care about the app. Let's say that we're in production now and like sweet, we have webpack, this is going to be awesome. I'm going to debug something in my bundle JS file, wait like no source maps, so like good luck with life.
You can pretty print it but yeah, have fun with that, so and especially as the app grow. So we're going to add source maps in our Webpack config and there are a couple of options. The first one that we're going to use is called eval. So you might think that I'm about to type a source map right.
That's not what I'm about to type. It's actually called devtool please don't ask me why. Yeah, but the devtool is going to be eval.
Kent C Dodds: So let's go ahead and we'll come back to the production version of source maps here in a little bit. But let's go back to npm run dev and see what this devtool's going to do for us.
So here we'll get rid of that, get rid of that. There's a here in our sources tab. We're going to have now a webpack:// that is not a protocol. That's just this source maps for our web back stuff so inside if you will find bootstrap. And you can also find out the normal way bootstrap.
But it's like pretty much not modified it just has this for which can be helpful. And it has our code in it. And so this is a lot easier to debug you can refresh and you have your breakpoint there. And you can get the same experience with production.
So if we say an npm run build and then we and then npm start.
Kent C Dodds: We'll refresh and we have bootstrap here as well. So then we refresh we can hit a break point we can step over code all that stuff but that actual bundle file itself well it's formatted now but.
The bundle is minified the problem though is that if we look at this bundle we have all the source maps in line in the file. We're sending all the source maps to the users of our app don't want to do that. And so there are a couple reasons that we want to use eval in the first place eval is really, really fast to generate.
So really fast for a webpack to build it's also really fast for webpack to rebuild. But you're shipping source maps to customers, that's not what you want to do that that will slow down your load time for your app. And so what we're going to do is we need to somehow determine in this function when we're generating our webpack config.
We need to determine whether we're in production mode or if we're in development mode. And if we're in development then we'll use eval, if we're in production then we'll use this one which is called source map.
Kent C Dodds: So if we run the build this time we're going to see that in our disk directory we see bundle J.S. and then bundle jazz map.
So here we'll see. Now it's not quite so big. And it has this mapping to our source map. And so now the only thing's that's getting shipped to our customers is our actual code and then the URL to our source maps. And this is like the most common way that people do source maps for production.
So any questions about how that's working?
Student: Those source maps don't get loaded unless they open up the dev tools correct?
Kent C Dodds: Yeah, thanks for bringing that up. Yeah, so.
Kent C Dodds: Yeah, so like the browser one actually open load those source maps and tell you open dev tools.
So if I, let's npm search. I refresh here and then I open up my dev tools. I'm going to look at my network. Well, I actually can't show you how that works because like my dev tools are open. But yeah, it loads up it loads up once a open mind at tools which most of your customers want to do and if they do then maybe they want to look at your code.
I don't know. How fun with that.