در حال بارگذاری ...

Intro to file versioning0:00

Alright, let's move on to long-term caching. We'll talk about file versioning in this video. So I've reduced our webpack.config.js file to remove the CSS purification and some of the Sass extraction. You still want to keep that, I'm just doing it to keep this file easy to consume and not overwhelming. So we have about 45 lines, very simple, this should all make perfect sense to you right now. Okay, so take a look. We have our app entry point, and when we compile this down, we come back, sure enough, the

Using hash placeholders0:22

Okay, so take a look. We have our app entry point, and when we compile this down, we come back, sure enough, the generated file name is app, and it's getting that because we named the entry app, and then for the output, we used this wildcard called name, or placeholder. So that means if I were to say main, and we delete this, if we run it again, well now the file will be called main, and sure enough, it is. But now, what about this? There's more than one placeholder. So for example, I could use a hash here, name.hash, and when I do this, Webpack's going to generate a unique hash for the build, and apply that wherever we request.

So for example, I could use a hash here, name.hash, and when I do this, Webpack's going to generate a unique hash for the build, and apply that wherever we request. So if we run this now, you'll see that we get not main.js, but main.hash.js. And the useful thing about this is, when we serve this to production, we can teach our server and teach the browser to cache it for a very long period of time. And as long as that hash does not change, the browser won't have to fetch a new copy of the code, because it hasn't changed, so it can cache it as long as possible. So that can be very useful. But now, well what if we had more than one entry point? So like maybe we have a vendor entry point, and it's just going to have maybe jQuery.

Multiple entry points issue1:30

But now, well what if we had more than one entry point? So like maybe we have a vendor entry point, and it's just going to have maybe jQuery. Okay, well if we run that, I think it's going to fail, right? Yep, it is. So in this case, it can't resolve jQuery, because we haven't installed it. Okay, npm install jQuery, and I'll save that to my devDependencies list, or regular dependencies are fine. Okay, so if we give that another run, it's going to compile. But now I want you to take a look that, yes, it created a vendor and main file, but the hash for each one is identical.

But now I want you to take a look that, yes, it created a vendor and main file, but the hash for each one is identical. So think about that, and let's delete this so we get a fresh run. We'll talk about clearing out that directory at the end of the video. Anyways, so we get our bundle, but now each file has the exact same hash. So if I were to change this, and give this another run. So note that before it was 30e, and now with the new bundle, each file gets a new hash. And this defeats the entire purpose, right? I haven't changed my vendor library that contains jQuery, but because I changed my application.

Switching to chunkhash2:30

And this defeats the entire purpose, right? I haven't changed my vendor library that contains jQuery, but because I changed my application code and I recompiled, well, Webpack prepared a new hash, and it applied it to each. So this defeats the entire purpose. We want long-term caching, but every time we bundle it up, we get a new hash, which will signal to the browser to refetch it. So not quite what we want. It sounds like instead we want a content-specific hash. Let's do this. We're going to change this to chunkHash.

Let's do this. We're going to change this to chunk hash. So now it's going to be a specific hash that corresponds to the current chunk, and the current chunk would be main or vendor. Okay, so let's give this a shot. Now when we run it, I think you'll find, yeah, we have unique hashes for each. So this is a specific hash for the contents of the vendor library or file, and then this one is for main.js. And this is exactly what we want. So take a look.

And this is exactly what we want. So take a look. If I now do change main.js and we run it again, note that, yes, you'll get a new main.js file, but the vendor chunk didn't change at all, so we didn't have to create a new hash for it. It can remain exactly the same. And this is what allows for long-term hashing. Now there's actually a number of configurations we can make here, but one step at a time. Now you can see, though, that every time I compile, I'm getting a new file, right? So if we change some code, save it, run it again, we're going to get yet another main.js file.

Cleaning old build files3:53

Now you can see, though, that every time I compile, I'm getting a new file, right? So if we change some code, save it, run it again, we're going to get yet another main.js file. So we can pull in, there's actually a number of ways to do this. With Laravel Mix, the way I set it up is I read all of the files from the previous bundle and we remove any of the old hashes. And that allows you to place a versioned file anywhere you want. A more traditional approach is to throw everything within a build or a dist directory and then just have Webpack clear out that directory for each compile. So we should be able to use a clean Webpack plugin for that. Let's hunt it down.

Adding CleanWebpackPlugin4:29

So we should be able to use a clean Webpack plugin for that. Let's hunt it down. Yeah, here we go. So let's see. We pull, let's go through to GitHub actually. All right, so we will install this and then we new it up as a plugin and you give it a path to the directories that you want to clean. Okay, so let's give that a shot. I'm going to pull this in and then we will, let's just grab this, switch back to webpack.config.js, paste it in, and then finally we will new up a plugin.

I'm going to pull this in and then we will, let's just grab this, switch back to webpack.config.js, paste it in, and then finally we will new up a plugin. So we'll switch back down to our plugin section and we can add that right here. Okay, so here's what we're saying. We want to clean these directories. We're only interested in dist for now. Root, think of that as, well, what's the project base folder so that I can find dist. In our case, it will just be the current directory. Verbose, do we want logging? Sure.

دوست دارید گاهی خبرهای Laracasts را ایمیل کنیم؟