Kent C Dodds: Even with WebPack, this is what our dependency tree looks like. It's just a bunch of random files that may or may not be dependent, it's just script tags, right? We just are saying, okay, we replaced our bootstrap JS with this bundle JS, it's really not getting us anything from a dependency perspective.
So this next module is about making those dependencies a little bit more tied together. So the exercise was this and we're going to skip it because like I said, this one was a little bit more monkey work set of things. But yeah, so here inside of our app, we identified all of the modules that this app requires, this app module itself.
And so, all of these modules attack something onto the app global, right? So that's even, this app module itself attacks on load, to the app global. And so what we're trying to do is pull away from global's and well, eventually, we'll pull away from global. You'll notice that we're still putting stuff on the global, but at least where requiring the specific files that we need and one thing that like is, like quite possibly happening in your apps right now with Gulper Grant, is you have files in there that you're concatenating with your whole app but are actually used by anything.
That's something that can't happen with WebPack because you have to explicitly require it. And if you have LinkedIn set up in place, then it will help you like know when you're not actually using anything from that, which is fantastic. And so, yeah, the goal of this one was to remove the immediately invoked function expressions because we don't need those anymore.
Remember those are like inside of like these are inside of a closure already, and then also to add require statements for anywhere that actually requires anything. So any questions about that, like even though we're skipping past this one, I do want to open it up for questions if anybody has any.
I should probably talk about what this is, but okay, yeah. So, let me just demonstrate for you really quick why that path info is useful because that is very specific to WebPack. So if I don't have the path info like we did before, I'll comment that out. I'll run npm run dev.
And then we refresh the browsers here. And if I look at the bootstrap file now that I'm requiring stuff, you can see that WebPack is replacing my required statements with WebPack require statements and it's giving a number here. That is not at all useful to me when I'm debugging stuff.
I need to know like what is that like, actually requiring, right? So, what the path info does is it's going to give us a little comment, that will tell us what that require was for. So, the reason that WebPack is putting an ID in here is because as your application grows you're doing more important require statements.
That's a lot of strings and that's potentially a lot of space and so it's doing an optimization just like, to reduce the amount of space. And so that's why you have your path info and we're using, if not prod from our FU tales. And so if you don't provide anything to if not prod, it defaults to a boolean.
So the path info value is true or false.