Check out a free preview of the full Webpack 4 Fundamentals course:
The "Chaining 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:

Chaining Loaders are transformations applied in a pipeline to the resource. Each loader passes values onto the next loader until the end loader, where Webpack expects JavaScript to be returned. Sean takes questions from students.

Get Unlimited Access Now

Transcript from the "Chaining Loaders" Lesson

>> Sean Larkin: And now, I wanna talk about chaining loaders. So, what's cool is that, like I said, you can apply an array. And so, since the anatomy of a loader is just a function that takes a source and it returns a new source. That's it. And so, in this specific case, loaders always execute from right to left.

[00:00:22] Now technically under the hood they actually go right left right. But the first pass going from left to right is actually just to collect metadata, and it's not really that important. The important thing is that, they are going from right to left. And I'm just going to show you an example in the editor really quick.

[00:00:41] You can think about it like this. Instead of, let's just say you had, so that was, style, css and less. That's how you should kind of think about it when you read it inside of the configuration. It's like you are calling each function. Yes?
>> Speaker 2: Yeah, can you have a module matched multiple rules in a rule set?

[00:01:11] Or does the only the first match count?
>> Sean Larkin: No, it's gonna apply against any rule and you can choose to have it only apply against one, like we have a way to do it There's a key called one of or any of and you can do either but, yeah.

[00:01:32] So it's super flexible. So you could choose to have it apply against both or it can be against just one. So the answer is yes. But just remember when it comes to the ordering, I think this throws people off because they're usually used to seeing things from left to right and going in order.

[00:01:48] But I always just remember this pattern. It's just like calling a bunch of functions. That's what they are, and they return new source values. Or you could do chaining style if that's what you like seeing. Where is it? There we go. So if you look at this little conveyor belt here, we have this.

[00:02:07] Let's just say your entry point was importing style.less, right? And so as just before WebPack is about to parse this file, we look to see if any rule sets match against this file, right. So style.less does in fact match this regular expression cuz it ends in .less. And so what we do is we're gonna apply the less-loader first which takes a, basically it just consumes the source and converts it to a CSS file.

[00:02:46] And then we're gonna take that CSS file now and pass it to the CSS loader. And what that does behind the scenes is it converts it to the style rules in memory as an array. That style-loader is equipped to consume. And then you'll see that once you pass that to style-loader, actually what happens is it converts it to a JavaScript module that says, all right.

[00:03:08] Take these styles, slap it in a script tag on the browser, right? So, and you might be thinking to yourself well Shaun, that doesn't really seem like best practice for performance, right? And it's true. Maybe for your critical styles you could use this. But there is lots of different ways of handling assets in Webpack.

[00:03:28] And so for example we have plugins that will extract this out into single bundles instead of trying to load it through JavaScript. But this is really just a showcase. Like, chaining, you can chain multiple loaders together. Like CSS loader and style loader are used together. But, they are separate loaders because they are meant to be one kind of single purpose.

[00:03:49] Single purpose modules that do one transform really well. And there are just a crazy amount of loaders. I tried to do a regx search for -loader and web pack on mpm registry and I found a crazy amount of stuff. Everything from collecting code coverage. You don't have to apply a transformation.

[00:04:10] A loader could just collect metadata and emit a file on disk, right? So the code coverage or like there's all sorts of stuff, things like responsive image handling. Like you could inject special JavaScript for images as you process them. You could compress images on the fly. You can handle typescript, and it enables you to use Babel, like everything.

[00:04:34] Pug, Hamill, like for me being from the Rails ecosystem. [LAUGH] And you can even, using Babble, preset PHP, right? PHP that runs and is converted to JavaScript. Yes. And as Tom Dale said, where is your god now? [LAUGH] Yes. And the possibilities are endless, because it's super easy to create a loader if it just takes a source and converts it to whatever you want and returns that source.

[00:05:12] And so like loaders really it tells Webpack how to interpret files. How are you gonna process certain types of files? And it matches and applies transformations on a per-file basis, based on the result path of that file. And before it gets added to the dependency graph.