Entry and Context | webpack

The entry object is where webpack looks to start building the bundle. The context is an absolute string to the directory that contains the entry files.
The base directory, an absolute path, for resolving entry points and loaders from the configuration.
By default, the current working directory of Node.js is used, but it's recommended to pass a value in your configuration. This makes your configuration independent from CWD (current working directory).
string string[] EntryObject EntryFn
The point or points where to start the application bundling process. If an array is passed then all items will be processed.
A dynamically loaded module is not an entry point.
A rule to consider: one entry point per HTML page. SPA: one entry point, MPA: multiple entry points.
If a string or array of strings is passed, the chunk is named main. If an object is passed, each key is the name of a chunk, and the value describes the entry point for the chunk.
If an object is passed the value might be a string, array of strings, or a descriptor:
Descriptor syntax might be used to pass additional options to an entry point.
The html option 5.108.0+ generates an HTML file for this entrypoint with its JS and CSS output chunks injected. It accepts the same values as output.html and, since webpack 5.110.0, an object that overrides it option by option for this entry, so a single entry can opt out of page generation or change just its title:
output.html.inline is resolved once per generated page and can only be set on output.html.
The worker flag (added in webpack 5.108.0) marks an entry as a worker so its output file uses output.workerChunkFilename instead of the regular chunk filename. webpack sets it automatically for entries it creates from new Worker(new URL(...)), so you rarely set it by hand.
By default, the output filename for the entry chunk is extracted from output.filename but you can specify a custom output filename for a specific entry:
Descriptor syntax was used here to pass filename-option to the specific entry points.
By default, every entry chunk stores all the modules that it uses. With dependOn option you can share the modules from one entry chunk to another:
The app chunk will not contain the modules that react-vendors have.
dependOn option can also accept an array of strings:
Also, you can specify multiple files per entry using an array:
The array form is also how polyfills are loaded, because the order of an entry array is the order the files run in. Anything a polyfill repairs has to be repaired before the application touches it, so the polyfill goes first:
Importing all of core-js/stable ships every polyfill regardless of what the code uses or what the browsers need — 637 modules, 215 KB minified and 71 KB gzipped with core-js 3.50. Prefer @babel/preset-env with useBuiltIns: 'usage' and a browserslist query, which imports only the polyfills your source actually reaches and your targets actually lack.
See Loading Polyfills for when a separate polyfill entry is worth the extra request, and Serving a smaller polyfill to modern browsers for building the same source twice so modern browsers download less.
If a function is passed then it will be invoked on every make event.
Note that the make event triggers when webpack starts and for every invalidation when watching for file changes.
In some scenarios, you might want to organize your entry points into different folders for better structure and maintainability. Here's how you can define multiple entry points located in different folders:
For example: you can use dynamic entries to get the actual entries from an external source (remote server, file system content or database):
When combining with the output.library option: If an array is passed only the last item is exported.
It allows setting the runtime chunk for an entry point and setting it to false to avoid a new runtime chunk since webpack v5.43.0.
optimization.runtimeChunk allows setting it globally for unspecified entry points.
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