Tree Shaking

[00:00:00]
>> Sean Larkin: But okay. So why don't we actually bundle this code again in production really quick before we take a break? And,
>> Sean Larkin: So build it for production. We'll add a web pack config and set the mode to none and we can understand how the runtime works. But let's just do mpm run prod

[00:00:22]
>> Sean Larkin: Let's see what happens. Okay. So, of course, it's a small amount of code, I mean, probably the output is still a little bit larger than what we've actually written. But, I want you to search for the strings red and blue.
>> Sean Larkin: Do you see the red or blue string in there?

[00:00:49]
No, you don't. This is what is called dead code elimination or tree shaking. It's the fact that Webpack is using statically the syntax to identify what am I using? Think about this impact in terms of lodash. If you're using only one lodash function, you should only be bundling one function, right?

[00:01:13]
That's super important. So let's actually take a look and understand how this is working. We get what it's doing, but I think it's really valuable to actually break this down. So for the first time, well, here, I'm gonna actually stop. I'm gonna save a new branch. Cuz I think I deviated just a little bit from what the branching is.

[00:01:37]
So I'm just gonna do a new branch checkout. So, git checkout -b feature/031-all-module-types. And we'll check that out. Get add all, get command, let's see. Cool. M, 031 all module types. Yay! So now if you are lost or you guys felt like you are missing a point, at any time you can just go ahead and jump into this branch 03 run all module types.

[00:02:20]
Okay, so why don't we go ahead and add our first web pack configuration? And don't worry. But like when you think about it out of the box. If like all you're trying to do is just build JavaScript. Like let's say you don't wanna handle CSS. You don't wanna handle html.

[00:02:35]
This is the only tool you need. Cuz literally as long as you are writing modules, you can have, that can be web pack's core purpose. That is its purpose as a core library itself. Now of course we have all these other things and the ecosystem enriches it and makes it.

[00:02:54]
Cuz you might ask the question. I wish I could also have incremental recompiling on my styles and why can't it be tied to modules if those change. There are dependencies. And so that's kind of where loaders were born, but let's add a web pack configuration. And so by default, web pack, when it runs, all it's doing since it's node, it just doesn't require, relative to the local path webpack.config.js.

[00:03:26]
That's all it's doing, it's just requiring this file or it attempts to try to. So go ahead and create that. And what we can do now is, we're gonna create a object that is default exported. So maybe now that you hear that you're like, I get that okay, modular exports equals an object, okay?

[00:03:52]
Half way there, half way there. Okay, so of course does this break anything if I run Webpack? Like I don't know. Nope, because web pack applies its defaults after it requires the config. So all this does is allow you to override any of the default behavior. So in this case we wanna add mode, and set it to none.

[00:04:13]
That's all we're doing. We just wanna explore the outputting code. And so this will just say, webpack, bundle it but don't wrap it in evals. Don't do anything crazy. Just do what the default behavior is. And so now if we run, let's see, yarn, I bet, let's go back to, let's go back.

[00:04:32]
So we have just webpack webpack. We should just run it without passing any args to it. So let's just say mpm and webpack. Okay, cool, it still builds, does everything I expect