Compiler Walkthrough

[00:00:00]
>> Sean Larkin: And so now you see this example again, right? So, we pass the configuration to webpack, it consumes it, and reads the entry property. So, we basically, we don't know if that entry exists, so we have to go through the normal module factory, which calls out to the resolver and says, hey, I don't know if this exists.

[00:00:25]
Can we verify this, please, and so it goes and searches. If it finds it, it says, hey, we're good. It's here, and it returns the full path information, and some other context and useful data, and passes it back to the normal module factory. What that does is it creates this object now, collects the source information, and now we have the source for the module.

[00:00:49]
Now what webpack does from here is it has to take that source and it's gonna parse it into an AST. It walks through the graph looking for dependency statements, and as it finds it, it's going to attach one to the module.
>> Sean Larkin: Then, when you think about it, those dependency statements, even if you look back at the AST explorer, you'll notice,

[00:01:14]
>> Sean Larkin: Inside the import declaration, what's the problem here? We couldn't just go pull a source from here, right? What would we have to do with that? If you look at the value property here it's corresponding to that little piece. What would we have to do before we could collect this source?

[00:01:36]
>> Speaker 2: Resolve that path.
>> Sean Larkin: We'd have to resolve that path, absolutely. So, we literally repeat the process for every dependency on that module. So it's a breadth-first search graph traversal. So we essentially repeat this process until there are no more dependencies to be resolved, right? Make sense? And that is entirety of webpack, how it creates the graph.

[00:02:06]
So, you'll also see a little corner down there, and it says loader runner. So, if it's not JavaScript, or if there are conditions like the rules, the regular expressions that match against that result path, what happens is that those loaders functionally transform that file until it's JavaScript, and then it parses, and goes through the exact same process.

[00:02:35]
So, now we get to the rendering portion, and so I made this little comic, I think it's kind of cool, maybe. Hey, I'm a module! I can't wait to work in the browser! And the compilation's like whoa! Stop! You are not ready. You are not ready for the big stage.

[00:02:53]
So first you need to jump in this retainer we call a chunk, and we're going to be throwing a lot of plugins at you, and topically sorting and optimizing you, we don't want to lose you. So we need to keep track. Now we're almost there, but those required import statements have to go.

[00:03:09]
They don't work in the browser, so the parser gave me special instructions for rendering your dependencies. We call them dependency templates and dependency factories.
>> Sean Larkin: And then of course the render occurs, and it's like, my god I'm finally rendered. Here I come browser-land, I'm so ready. So literally, this is how webpack works in its entirety.

[00:03:36]
That's webpack, that is everything on how it works under the hood. That's all it is. You could even break it up into three main stages, or like three steps. One, which is build the graph. Two, which is optimize the graph, and three, render it, and we just use templates, so it's data binding.

[00:03:55]
Does that make sense? Do you have questions so far? I think that this knowledge is super-important. Why do I teach you about the topical instances? Because that's the, I shouldn't say crap, but that's the crap you plug into. It's like, any of this behavior that you just learned, is completely over-ridable.

[00:04:13]
Completely extensible. Completely, you can have it do anything you want, and that's why plugins are so powerful.