Alright, so at the moment, if I were to run npm run build, yes, that compiles down, and if we take a look, here's our bundled JavaScript. But we may know that for production, ideally this should all be minified. We want the file size to be as small as possible. So let's figure out how to do that in this episode. Now if we come back, you've learned about loaders here, but there's also the concept of plugins, which are very much the bedrock of Webpack. And in fact, Webpack itself is built on top of this concept. So you can add plugins for everything from generating manifest files, to uglifying code, or to changing the hash that gets supplied to files.

So you can add plugins for everything from generating manifest files, to uglifying code, or to changing the hash that gets supplied to files. They can basically do anything you would want. So we're going to scroll down and reference an array of plugins. Now in our case, we want to minify our code. So what I could do is say new Webpack.optimize.UglifyJsPlugin. So let's give that a shot. We're going to run this, and it's now going to apply uglify as part of the build, and that should minify the code. So if we switch back, there we go.

that should minify the code. So if we switch back, there we go. Very, very easy. But now the issue is, well, for development, I don't want that minified. I'm only interested in that for my production builds and my production deploys. So what can we do here? Well, we might do something like this. We could say at the bottom, so what if we did something like this? Let's say if process.environment, if we have any reference to nodeenv, and if that's equal to production, then we can assume, oh, we want to trigger this in a production environment.

Let's say if process.environment, if we have any reference to NODE_ENV, and if that's equal to production, then we can assume, oh, we want to trigger this in a production environment. So in that particular case, we could say module.exports.plugins, and now here is where we will push our uglify plugin. Webpack.optimize.uglifyJsPlugin. OK, so let's give that a shot. But right now, we know that we're not setting the NODE_ENV to production, right? So if we take a look, yep, we get the full unminified code. However, let's set NODE_ENV this time. We'll say NODE_ENV is production, and then once again, we'll just trigger Webpack.

a costly thing. So we only want to do that for our production builds. So now let's come back to package.json, and it sounds like we can add another one. Our production build, or prod if you want, we can say NODE_ENV is production, and then trigger Webpack. Now, what you could also do on that node, if we run Webpack, you'll see at the very top there is a dash -p flag we can apply as well, and that will define a few things. But I'm going to leave that off because we'll do that manually a couple episodes from now. OK, so you have your development build, and why don't we just call it development since that's what we're doing here.

OK, so you have your development build, and why don't we just call it development since that's what we're doing here. npm run dev. That compiles down. You have your full code, or npm run production. And that will do the same thing, but with a production environment. So now we have a flag we can use to adjust what sort of actions take place. And you'll find even for things like view compilation, yeah, it does need to know are we in development mode? Should we show warnings and things of that nature?

we in development mode? Should we show warnings and things of that nature? Or should we not? But this will get you started. Now, another thing you might want to do is if you want to save that to a variable, you could say var, and why don't we say inProduction equals that. Now, anywhere in your webpack file, you could say, well, if we're in production, then push this plugin. Pretty useful.