Webpack 4 Fundamentals

Output & Loaders

Sean Larkin

Sean Larkin

Webpack 4 Fundamentals

Check out a free preview of the full Webpack 4 Fundamentals course

The "Output & Loaders" Lesson is part of the full, Webpack 4 Fundamentals course featured in this preview video. Here's what you'd learn in this lesson:

Continuing to review Webpack concepts, Sean examines Output and Loaders. Output works in tandem with Entry telling Webpack where and how to distribute bundles or compilations. Loaders instruct Webpack on how to modify files before its added to the dependency graph.


Transcript from the "Output & Loaders" Lesson

>> Sean: So output, that's the second one. And we all kind of understand IO, and input output. And so like the output is kind of like, let's say you take that graph. Now that webpack has this graph internally in memory, it needs to actually create the bundle and we even explored kind of what the output looks like.

But the output here is really talking about where and how we're gonna name the file. And as you dive deeper, there are more configuration options for just output here. This is just one example. And it's scratching the surface really. But in this case, we're just providing a path that we want it to go, as well as a name for the bundle.

Now you saw in webpack 4, by default, actually file name is set to main.js. And the path is dist. So this will create a bundle and generate in a js folder called bundle.js. But the high level idea is that the output concept is really about telling Webpack where and how to distribute these files.

We sometimes call them compilations internally in our source code. And it works directly with the entry property. And so, the next concept is something that really stands apart from any other tool that you probably used. So loaders and rules. So like the concept of what a rule is, is that right now, or at least just right up until webpack 4, we have always treated every dependency as a JavaScript module.

And so what we've kinda created in the configuration here is like we're defining rules for how we want to treat files that are on JavaScript, or how we wanna treat files that match against one of these loaders. So like in kind of our terminology, we call this like a rule set.

And a rule set basically has two minimum criteria. One, which is, as webpack's creating this dependency graph, it's adding files to it, right? And so if webpack comes across something that matches one of these regular expressions here, this rules set basically says, okay, apply this node module, which is just a function behind the scenes.

And transform whatever file that comes across, as it's being resolved. And I'll show you in more detail how this would work behind the scenes. But essentially, what it's doing is it's transforming files that are being added to your dependency graph, and based on one of the loaders that are provided.

So you can think, when you're adding a different behavior to your configuration, you're adding a rule set and applying basically just a pattern to match. You're pattern matching the extension and applying a different type of transform to it. And this is a per file process. So, it's not something that just happens in bulk, and there's a very specific reason for that.

I tried to diagram it here, but you can kind of think about it like this. So, this is our same graph, but you'll notice that each of these maybe has a different behavior about it. This entry file might be importing a .ts file. Well, webpack's not gonna understand typescript out of the box, and it would throw out errors trying to parse that file.

And so what this ruleset does is, it basically says any time that you're trying to add a dependency to the graph, if it matches this extension, apply this transform. And so as it's going, it finds this file is transformed to JavaScript, it might also have dependency statements. So as webpack continues to traverse, it might come across something like, I don't know, has specific ES syntax.

And even though Webpack could parse this, you probably don't support a specific syntax in the browser, so you'd wanna transform it. So there is a very specific use case for why we even use Babble. And so we basically say, any time we come across a JavaScript file, apply this transformation to it.

So on a per file basis. And in the same way, let's say this dependency is importing a CSS file. You can do that with webpack and if that happens, it's going to once again match against one of these rule sets and apply a transformation. And that's kind of what like the rule set is at a top level.

And there are different types of features that help you filter and include or choose to ignore when you want to transform a file or not. There's things like include and exclude which are like, ignore any files that are coming from the known modules folder. Or let's say, use itself is where you actually pass the loader node module string.

And so you could choose to do it conditionally, or you can apply a chain of loaders. Or you could say I want it enforce. You could say I want this to run before every other loader or after every other loader. So there's lots of different behaviors and ways that you can configure.

But really this is the minimal, like this is the minimum use.
>> Sean: And so thereའs lots of different options and they're really kind of like used case based. So knowing about them is helpful. But you won't have to memorize any of these specific properties. I think I kinda used this example early on where it was like, if I want to import some of my tests but I don't wanna actually import, I don't wanna use them or transform them In like production mode.

And so, I'll exclude any of my spec files and things like that. And that's kind of how include and exclude might work.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now