Check out a free preview of the full Webpack 4 Fundamentals course:
The "File Loader & URL Loader" Lesson is part of the full, Webpack 4 Fundamentals course featured in this preview video. Here's what you'd learn in this lesson:

Sean reviews common loaders such as the URL Loader, which moves or emits files into the output directory.

Get Unlimited Access Now

Transcript from the "File Loader & URL Loader" Lesson

>> Sean Larkin: So before we dive in to presets, I think there is a couple other,
>> Sean Larkin: Any, how would I say this? Must haves or common loaders that you're gonna come across. I have a list here that I like to keep track of so I don't forget. Or what are some other dev tool capabilities?

[00:00:20] A lot of them we're able to just provide out-of-the-box with webpack with v4, because we could make distinctions between your development environment and not. So two great examples that we're gonna add to our basic configuration is gonna be CSS, or not CSS loader, URL loader and file loader.

[00:00:44] So why don't we install those dependencies, npm install file-loader and url-loader. So go ahead and do that, let me do -dev.
>> Sean Larkin: All right.
>> Sean Larkin: So, there's a couple applications or reasons you would wanna use this. I'm gonna try and give you some of the easiest or the most pragmatic ways.

>> Sean Larkin: But really, at least just try and show you the simplest functionality and then you'll have the confidence to kind of be like, well, wait we could do this as well or we could apply it to other scenarios. So the idea is that, let's add them to our configuration first.

>> Sean Larkin: All right, so, now, we're on our base configuration, we have module, and we'll add two rules or two rule sets.
>> Sean Larkin: So, the test property is the part that may change or may depend based on what kind of assets you're loading. So this is kind of like an all around fallback to say, what if I have something that doesn't map to a browser API, or is a source like an image, or let's say a video, or some type of audio.

[00:02:33] I think for me, the pretty basic one is JPEG.
>> Sean Larkin: And so what we would wanna do is take and, we would either wanna base 64 and line this or we would just wanna emit this to our output directory, right? And that's what URL loader does for you.

[00:02:55] So you could say use url-loader.
>> Sean Larkin: And I would encourage you to, let's grab just any image, I don't think it really even matters. If we all wanted to grab the same one which I always think is fun we could go to And so we have a branding guide for webpack or if you are ever gonna reference our logos.

[00:03:23] One, check the license that governs it. And then also, we have a bunch of different assets that correspond and also our style color pallets, etc. And so, let's see, why don't we pull down something like this single JPG file. We can just download it,
>> Sean Larkin: Let's save image, cool.

[00:03:51] I'm just gonna save it directly to that repo. Cuz that's easier way, right?
>> Sean Larkin: Webpack logo dot, there we go, well, be .jpeg. Cool,
>> Sean Larkin: So now I guess since it's a regular expression and sometimes you get .jpeg and .jpg. Regular expressions are really nice because it helps you match a variety of different extensions.

>> Speaker 2: For that, you use string? That one seemed pretty self apparent that it would be URL loader, but are they just gonna match the NPM module names? Generally.
>> Sean Larkin: Correct, yes. So that's a really good question and we can talk about that. So you might say, Sean why do we import plugins, but why do we only pass node module references for these loaders, right?

[00:05:01] [LAUGH] The short hand reason is because, so loaders are serialized. Basically, the first premise with Webpack is that when loaders were originally invented, the way that you were using them actually was doing something like this, css-loader!. And this syntax still works today technically. But we heavily encourage people not to because it's not valid.

[00:05:31] I mean sure, I know this is not really a valid CSS or JavaScript, but this way,
>> Sean Larkin: Essentially, what happens is that we stringify and we serialize this entire request, but sometimes you can add options and even functions as options, and those aren't serializable. And so we have to get really crafty, we couldn't just pass a function itself in the config, or a function object cuz we need to be able to serialize that information, and then we parallelize it.

[00:06:05] And so it's kind of like an architecture constraint. We've considered trying to normalize it into just all plugins. I think now that we've added this X as module type where we cannot create new module types in Webpack 4. We may see the usage of loaders for things like CSS maybe less common and maybe more like for pre-processing and stuff like that.

[00:06:31] So that's kind of the short reason if that kinda answers your question.
>> Speaker 2: Yeah, but the rule of thumb is, it will always be the NPM module.
>> Sean Larkin: Exactly.
>> Speaker 2: Okay.
>> Sean Larkin: Absolutely.
>> Speaker 2: I've run into some confusion with that before I said.
>> Sean Larkin: Yes, now you can customize this because the resolver uses our same Webpack resolver.

[00:06:50] If you are going to write a custom loader, and we'll learn that tomorrow, if that's what people wanna learn about. Is that you have to if you wanna have your function locally, you can do so but you have to have a special resolution pattern for it. Just set up an alias essentially, but yeah.

[00:07:06] So this is always referencing the path to that inner module.
>> Sean Larkin: So nice, if we go ahead and just run, we could run our dev mode. We haven't done anything yet, technically. So, we shouldn't see anything too fancy and