The server can be configured to tell the browser how long to keep these assets around, or whether to cache them at all.
Depending on your application, it may actually be better to configure your server to tell the browser to keep these cached assets around indefinitely. Then when it comes time to update your application, you simply update your script tag to point to an entirely different URL. Then, the browser has to download that new asset.
Webpack comes with special syntax for properties in this output object to allow you to change the URL for these different assets.
So, the browser knows that it has to download those files. Let's go ahead and use that syntax now. In the filename property, we're going to add .chunk hash. What that's going to do is if we run the build, the output has this bundled. -- and then this -- hashstring.js. This will be uniquely generated every time we change our source code.
But now, if we run the server and we refresh the browser, we're going to have a problem. That's because our index HTML is still pointing to this bundle.js file. So, we can no longer hard code our script tag as we have in our index HTML down here.
This bundle.js is going to have to have the chunk hash right there. However, that's not going to work either because our index HTML is simply being copied from on directory to another when we start our server.
So, we need to know what the chunk hash is actually going to be, and generate this index HTML based off of that chunk hash. We can do this simply with the HTML webpack plug-in. Let's go ahead and install that MPM install as a dev dependency HTML webpack plug-in. With that installed, we can double check that's installed here with the HTML webpack plug-in.
We can go to our scripts, here, where we have copied files. We're no longer going to be copying the index HTML to the disk directory. We'll leave that up to this new plug-in we've installed.
Now we'll go to our webpack config. We'll require that plug-in. Now we can simply add a plug-ins array here, with a new HTML webpack plug-in where the template is index.html. If we open up our file tree viewer here, we can see that the index HTML is inside of this source directory. Our context here is that source directory. That's why the template can be relative to that source directory.
There's one last thing that we have to do. Because the index HTML is now going to be automatically generated and it's going to have our bundle added to it as a script tag, we can go to our index HTML and remove the script tag line there. The HTML webpack plug-in is going to automatically add that to our index HTML for us.
Let's go ahead and save this. We can run MPM start, refresh our browser. Now we'll see in our elements, we have a script with our bundle with that hash that we need to be able to deploy this application with the right script. This will be updated every single time we change our source code. That's how you leverage long term caching with webpack.
It's notable that if you were to combine this with the commons chunk plug-in, you'd have to do a couple extra steps, but that's something for another lesson.
Let's go ahead and review everything that we did for this. First, we installed the HTML webpack plug-in. Then we updated our copy files script, because we no longer need to do that manually. That's going to be handled by the HTML webpack plug-in.
Then, we went to our webpack config. We required the HTML webpack plug-in. In our plug-ins array, we added a new one specifying our template as the index HTML being relative to our context. Then we updated the index HTML to remove the script, because the HTML webpack plug-in is automatically going to add that for us.
It's also notable that the HTML webpack plug-in takes a lot more options. So, I recommend that you take a look at the documentation to see what would apply for your specific use case. That's how you can leverage the browser's long term caching with Webpack.