Output Management | webpack

This guide extends on code examples found in the Asset Management guide.
So far we've manually included all our assets in our index.html file, but as your application grows and once you start using hashes in filenames and outputting multiple bundles, it will be difficult to keep managing your index.html file manually. However, webpack can take the page over for you.
First, let's adjust our project a little bit:
Let's add some logic to our src/print.js file:
And use that function in our src/index.js file:
Let's also update our dist/index.html file, in preparation for webpack to split out entries:
Now adjust the config. We'll be adding our src/print.js as a new entry point (print) and we'll change the output as well, so that it will dynamically generate bundle names, based on the entry point names:
Let's run npm run build and see what this generates:
We can see that webpack generates our print.bundle.js and index.bundle.js files, which we also specified in our index.html file. if you open index.html in your browser, you can see what happens when you click the button.
But what would happen if we changed the name of one of our entry points, or even added a new one? The generated bundles would be renamed on a build, but our index.html file would still reference the old names. Let's fix that by handing the page to webpack.
If you inspected print.bundle.js, you might have noticed that it did not contain the printMe function. Instead, it contained only an IIFE with no observable side effects. This is because in our current setup, webpack treats each entry point as a standalone program that runs when the bundle is loaded. Because print.js only exports a function and never calls printMe(), executing it as its own entry does not require any executable runtime code. Thus, webpack is able to omit that code as an optimization since it would have no observable effect. In contrast, since index.js imports and uses printMe, webpack includes that function directly in index.bundle.js. Remember that webpack is a module bundler, so index.bundle.js contains all the code it needs to run rather than unresolved import statements. Multiple entry points are used here solely to demonstrate output management. In a real project, you would typically avoid creating a separate entry point for utility modules like this. If you do have multiple entry points that share dependencies, see Prevent Duplication in the Code Splitting guide.
Webpack understands HTML natively behind experiments.html: point entry at an .html file and the page joins the build. Every <script src> it references becomes part of the module graph, and the emitted page has those URLs rewritten to the generated filenames — so the page and the bundles cannot drift apart.
Move index.html out of dist/ and into src/, next to the files it refers to:
The tags point at the files you actually wrote, not at build output. Now adjust the config to build the page rather than the two scripts:
There is no list of entry points to keep in sync any more — the page states which scripts it needs, and output.htmlFilename says where the built page goes. Let's see what npm run build generates now:
Webpack has written dist/index.html for you, with both <script> tags rewritten to the bundles it just emitted. Rename an entry, add a script tag, or turn on hashed filenames, and the page follows along on the next build.
The page itself emits no JavaScript, so the scripts it pulls in take the entry's filename: main.bundle.js for the first, main1.bundle.js for the second. If you would rather keep named JavaScript entries and have webpack scaffold a document around each one, set output.html instead; the Native HTML guide walks through both models, along with titles, meta tags, favicons and templating.
As you might have noticed over the past guides and code example, our /dist folder has become quite cluttered. Webpack will generate the files and put them in the /dist folder for you, but it doesn't keep track of which files are actually in use by your project.
In general it's good practice to clean the /dist folder before each build, so that only used files will be generated. Let's take care of that with output.clean option.
Now run an npm run build and inspect the /dist folder. If everything went well you should now only see the files generated from the build and no more old files!
You might be wondering how webpack and its plugins seem to "know" what files are being generated. The answer is in the manifest that webpack keeps to track how all the modules map to the output bundles. If you're interested in managing webpack's output in other ways, the manifest would be a good place to start.
The manifest data can be extracted into a json file for consumption using the ManifestPlugin.
We won't go through a full example of how to use this plugin within your projects, but you can read up on the concept page and the caching guide to find out how this ties into long term caching.
Now that you've learned about dynamically adding bundles to your HTML, let's dive into the development guide. Or, if you want to dig into more advanced topics, we would recommend heading over to the code splitting guide.
Copyright OpenJS Foundation and webpack contributors. All rights reserved. The OpenJS Foundation has registered trademarks and uses trademarks. For a list of trademarks of the OpenJS Foundation, please see our Trademark Policy and Trademark List. Trademarks and logos not indicated on the list of OpenJS Foundation trademarks are trademarks™ or registered® trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.
The OpenJS Foundation | Terms of Use | Privacy Policy | Bylaws | Code of Conduct | Trademark Policy | Trademark List | Cookie Policy