Transcript from the "Setting Up webpack.config.js File" Lesson
>> Brian Holt: I could show you how to do this with the command line. So you can actually start like configuring Webpack through the command line to do this. Let's just build a config file so that we don't have to do that any more. So go ahead and make a new file and put it in the root directory of your project.
[00:00:19] Called webpack.config.js.
>> Brian Holt: What we're gonna do here is we're gonna say const path = require path
>> Brian Holt: Now this is meant for node, right? This is not going to be transpiled. So we're not gonna use the ES6 modules because node does not yet understand ES6 modules. So we have to use CommonJS.
>> Brian Holt: Okay. Then we're gonna say Module.exports
>> Brian Holt: And we're just gonna put up bunch of stuff in here. Context;__dirname. What is this saying is that we're running this from our route directory, always. So you can run this from this-you can run Webpack from anywhere in your project and it's always gonna run from that root directory.
[00:01:19] That's what the context dirname translates to, dirname is just a node global variable that refers to that root directory of your project.
>> Brian Holt: Entry So for now, we'll just gonna have one entry which is going to be .js/ClientApp.jsx. This is the front door of your project, right? Everything is gonna be included out from here.
[00:01:54] Devtool, we're gonna do cheap-eval-source-map, I think that's what it is, I'll have to make sure that that's the case. There's several different types of devtools, like you can do false source maps and everything like that. This is the one that plays the nicest with all the tools that we're gonna use, that's why we're gonna stick with it.
[00:02:17] This is just saying inline all of my source maps into my bundled code. It's gonna make your bundled code bigger in development but it won't be included in production. And source maps, for those of you that aren't familiar with them, if I transpile from my source code to evaluative code, if I don't have source maps, when I click on the errors it's going to show me directly in the bundled code which is worthless, it's impossible to read.
[00:02:44] If I have, source-maps is actually going to show me like my code, it's gonna show me the pre-transpiled code, that's why we do source-maps.
>> Brian Holt: Output,
>> Brian Holt: Path and that's gonna be path.join(_dirname. 'public'). So path is a node module that just resolves Unix style relative paths for you.
[00:03:19] So if we do this dirname public we can be assured that it's always going to land on the public directory that we're talking about. No matter where we call it from our project. That's why we're using it [BLANK AUDIO] And file name. I call it bundle.js. That's a common thing to call it.
[00:03:42] But you could call it whatever you want to. [BLANK AUDIO] Okay. Resolve.
>> Brian Holt: Extensions.
>> Brian Holt: So if I say just you don't have to commit a copy on this line. But if I say const App = require./app right?
>> Brian Holt: This is the order that it's going to try a file extensions before it finds the correct one, right.
[00:04:17] So, I'm gonna say, .js, .jsx, and then .json. So, the first thing it's going to do is, it's going to try and see if I find a file called app like App with no file extension. That's the first thing it'll check. Then it's going say does .js exist?
[00:04:39] If that doesn't exist then it's going to say does .jsx, and if that doesn't exist it's going to try .json and if that doesn't exist than it fails. It's the order of resolution of those extensions.
>> Brian Holt: Stats. This is just the various things that you wanna report it back to you when you're building.
[00:05:01] So we're gonna say colors true, because I like colors. Reasons. This is gonna give you more useful error output. So definitely put that. And, chunks I don't think this one is useful anymore but, we're gonna put it in there anyway, this is just saying if your code is being broken up into multiple different chunks please tell me about that.
>> Brian Holt: And, then the last thing we're gonna do here is we're going to start using babble. So, modules, sorry not modules, module singular than rules inside of that which is actually not under, it's gonna be an array
>> Brian Holt: Okay,
>> Brian Holt: So this is going to be an array of rules that Webpack is going to use to apply different loaders to your code.
[00:06:04] Now what is a loader? A loader is just a plugin, it's actually not a plugin. Let's not conflate words. [LAUGH] It is a, A tool that Webpack is going to use on your code in some fashion, right. So, the first tool that we're going to be using is Babble, right.
[00:06:23] So, we're gonna give it the Babble loader, so that webpack will use Babel for us, right. That make sense? So, I'm gonna give it an object. The first thing we're going to do is give it a test of some sort. This can be a function, this can be a RegeX, this can be several different things.
[00:06:40] We're just going to use a RegeX.
>> Brian Holt: You're going to do / \. JSX?$/,
>> Brian Holt: And then we're gonna say loader: 'babel-loader'.
>> Brian Holt: I am, by no means, a RegeX expert. But what this means is the file extension for the file must be dot JS and possibly X, right.
[00:07:22] So that's a good question mark that X might be there and then the dollar sign means this must be at the end of the file name. So anything that ends in .js or .jsx run through Babel. That's what that means, cool? Okay.
>> Brian Holt: Loader, you're just telling it here this is the name of the loader that I want you to run it through.
[00:07:43] So it's gonna call Babel. And it says here, Babel, here's your thing. It's gonna call it with all the output from the file and then babbles gonna do something and than hand back to Webpack that's the contract that's going on here and just so you know you can say loaders and then give it an array of different loaders to run it through.
[00:08:03] Right now we just have one, we just wanted to run through babel loaders so we are gonna leave it at that,
>> Brian Holt: Any questions?
>> Brian Holt: Make sense, okay?
>> Brian Holt: Save it. Thanks to Prettier it's gonna be all nicely formatted. Okay, so now I can go to my command line.
[00:08:41] And notice before I was giving you the entry and exit. I don't have to do that anymore. I can just say webpack. It's automatically gonna pick up the config and it's just gonna do it for me.
>> Brian Holt: Now you're gonna notice that's gonna take significantly longer than it was before, why?
[00:09:05] Because everything is being run through babel and it's a pretty intense process. So again, we're introducing tools for the sake of ease but it comes of the cause of complexity
>> Brian Holt: And now, we went from having 700 kilobytes which was ridiculous to having 2 megabytes which is add further ridiculous.
[00:09:26] But again you have to remember now, that was including all the too, right. So, babel it's actually gonna add quite a bit of weight to our bundles as well. But when we go actually to minify Jsif and go to production it can be significantly smaller. In fact i can show you what it looks like.
[00:09:47] So if you put -p, this is saying hey i'm building for production, this is going to do a whole different set of transformations. And we save 0.15. Because we have all the source maps in there. Source maps are huge. They're gonna over double the size of your code.
[00:10:09] So, we'd have to drop the source maps too. We'll talk about performance and for production on the third day. So yeah, let's build and let's go see if everything works.
>> Brian Holt: Everything is still working.
>> Brian Holt: And looking good.
>> Speaker 2: Do you go back to your index? [INAUDIBLE]
>> Brian Holt: Yes, you'll just need to include public/bundle.js