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.
Usage: entry: string | [string]
webpack.config.js
module.exports = {
entry: './path/to/my/entry/file.js',
};
The single entry syntax for the entry
property is a shorthand for:
webpack.config.js
module.exports = {
entry: {
main: './path/to/my/entry/file.js',
},
};
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".
webpack.config.js
module.exports = {
entry: ['./src/file_1.js', './src/file_2.js'],
output: {
filename: 'bundle.js',
},
};
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: { <entryChunkName> string | [string] } | {}
webpack.config.js
module.exports = {
entry: {
app: './src/app.js',
adminApp: './src/adminApp.js',
},
};
The object syntax is more verbose. However, this is the most scalable way of defining entry/entries in your application.
An object with an 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.
webpack.config.js
module.exports = {
entry: {
a2: 'dependingfile.js',
b2: {
dependOn: 'a2',
import: './src/app.js',
},
},
};
runtime
and dependOn
should not be used together on a single entry, so the following config is invalid and would throw an error:
webpack.config.js
module.exports = {
entry: {
a2: './a',
b2: {
runtime: 'x2',
dependOn: 'a2',
import: './b',
},
},
};
Make sure runtime
must not point to an existing entry point name, for example the below config would throw an error:
module.exports = {
entry: {
a1: './a',
b1: {
runtime: 'a1',
import: './b',
},
},
};
Also dependOn
must not be circular, the following example again would throw an error:
module.exports = {
entry: {
a3: {
import: './a',
dependOn: 'b3',
},
b3: {
import: './b',
dependOn: 'a3',
},
},
};
Below is a list of entry configurations and their real-world use cases:
webpack.config.js
module.exports = {
entry: {
main: './src/app.js',
vendor: './src/vendor.js',
},
};
webpack.prod.js
module.exports = {
output: {
filename: '[name].[contenthash].bundle.js',
},
};
webpack.dev.js
module.exports = {
output: {
filename: '[name].bundle.js',
},
};
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.
webpack.config.js
module.exports = {
entry: {
pageOne: './src/pageOne/index.js',
pageTwo: './src/pageTwo/index.js',
pageThree: './src/pageThree/index.js',
},
};
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.