Entry Points | webpack

As mentioned in Getting Started, there are multiple ways to define the entry property in your webpack configuration. We will show you the ways you can configure the entry property, in addition to explaining why it may be useful to you.
In simple terms, an entry point tells webpack where to start building its internal dependency graph. Starting from this file, webpack recursively follows all imported modules and assets to determine what should be included in the final bundle.
The result of this process is later written to disk according to the output configuration, which controls where and how the bundled files are emitted.
When running webpack without a configuration file, the entry defaults to './src', which webpack resolves to ./src/index.js through resolve.mainFiles and resolve.extensions. If that file is missing — even if your src/ directory exists — webpack will throw: Module not found: Error: Can't resolve './src' in '/path/to/project' The error names './src' because that is the actual entry request; index.js is only the default file looked up inside it. To use a different entry filename, configure the entry option as shown in the sections below.
Usage: entry: string | string[]
The single entry syntax for the entry property is a shorthand for:
We can also pass an array of file paths to the entry property which creates what is known as a "multi-main entry". This is useful when you would like to inject multiple dependent files together and graph their dependencies into one "chunk".
When an array is provided for an entry point, webpack still creates a single entry chunk. All modules in the array are loaded in the given order and combined into the same dependency graph.
This pattern is commonly used to inject additional code before the main application entry, such as polyfills or development-only tools, without manually importing them in the application source.
Example: Injecting a polyfill
Single Entry Syntax is a great choice when you are looking to quickly set up a webpack configuration for an application or tool with one entry point (i.e. a library). However, there is not much flexibility in extending or scaling your configuration with this syntax.
Usage: entry: Record<entryChunkName, string | string[]>
The object syntax is more verbose. However, this is the most scalable way of defining entry/entries in your application.
"Scalable webpack configurations" are ones that can be reused and combined with other partial configurations. This is a popular technique used to separate concerns by environment, build target, and runtime. They are then merged using specialized tools like webpack-merge.
You can pass empty object {} to entry when you have only entry points generated by plugins.
An object of entry point description. You can specify the following properties.
dependOn: The entry points that the current entry point depends on. They must be loaded before this entry point is loaded.
filename: Specifies the name of each output file on disk.
import: Module(s) that are loaded upon startup.
library: Specify library options to bundle a library from current entry.
runtime: The name of the runtime chunk. When set, a new runtime chunk will be created. It can be set to false to avoid a new runtime chunk since webpack 5.43.0.
publicPath: Specify a public URL address for the output files of this entry when they are referenced in a browser. Also, see output.publicPath.
runtime and dependOn should not be used together on a single entry, so the following config is invalid and would throw an error:
Make sure runtime must not point to an existing entry point name, for example the below config would throw an error:
Also dependOn must not be circular, the following example again would throw an error:
Below is a list of entry configurations and their real-world use cases:
When building in production mode:
When building in development mode:
What does this do? We are telling webpack that we would like 2 separate entry points (like the above example).
Why? With this, you can import required libraries or files that aren't modified (e.g. Bootstrap, jQuery, images, etc) inside vendor.js and they will be bundled together into their own chunk. Content hash remains the same, which allows the browser to cache them separately thereby reducing load time.
In webpack version < 4 it was common to add vendors as a separate entry point to compile it as a separate file (in combination with the CommonsChunkPlugin). This is discouraged in webpack 4. Instead, the optimization.splitChunks option takes care of separating vendors and app modules and creating a separate file. Do not create an entry for vendors or other stuff that is not the starting point of execution.
What does this do? We are telling webpack that we would like 3 separate dependency graphs (like the above example).
Why? In a multi-page application, the server is going to fetch a new HTML document for you. The page reloads this new document and assets are redownloaded. However, this gives us the unique opportunity to do things like using optimization.splitChunks to create bundles of shared application code between each page. Multi-page applications that reuse a lot of code/modules between entry points can greatly benefit from these techniques, as the number of entry points increases.
As a rule of thumb: Use exactly one entry point for each HTML document. See the issue described here for more details.
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 | Tr