As we mentioned in the introduction, there are several ways to define entry properties in a WebPack configuration. In addition to explaining why it might be useful, we’ll show you how to configure the Entry property.

Single entry (shorthand) syntax

Usage: entry: string | Array < string >

webpack.config.js

const config = {
  entry: './path/to/my/entry/file.js'
};

module.exports = config;
Copy the code

The single entry syntax for the entry property is shorthand for:

const config = {
  entry: {
    main: './path/to/my/entry/file.js'
  }
};
Copy the code

T> What happens when you pass an array to entry? Passing an array of File paths to the Entry property creates multi-main entries. Passing in an array is helpful when you want to inject multiple dependency files together and graph their dependencies into a “chunk.”

This is a great choice when you are looking for a quick webPack configuration for “an application or a tool with only one entry point (i.e. library)”. However, there is not much flexibility with this syntax extension or scale configuration.

Object syntax

Usage: entry: {[entryChunkName: string] : string | Array < string >}

webpack.config.js

const config = {
  entry: {
    app: './src/app.js',
    vendors: './src/vendors.js'
  }
};
Copy the code

Object syntax can be cumbersome. However, this is the most extensible way to define entry points in an application.

T> “Extensible WebPack configuration” means reusable and can be used in combination with other configurations. This is a popular technique for separating concerns from the environment, build target, and runtime. They are then combined using specialized tools such as Webpack-Merge.

Common scenarios

The entry configurations and their actual use cases are listed below:

Separate application (APP) and common library (Vendor) entry

webpack.config.js

const config = {
  entry: {
    app: './src/app.js',
    vendors: './src/vendors.js'
  }
};
Copy the code

What is? On the face of it, this tells us that Webpack starts with app.js and vendors.js to create dependency graphs. These diagrams are completely separate and independent of each other (each bundle has a Webpack bootstrap). This approach is more common in single Page applications with a single entry point (excluding vendor).

Why is that? This setting allows you to use CommonsChunkPlugin to extract a Vendor reference from the “application bundle” to the vendor bundle. And replace the portion of the vendor reference with the __webpack_require__() call. If there is no vendor code in the application bundle, you can implement a common pattern called persistent caching in webpack.

? > Consider removing this scenario in favor of the DllPlugin, which provides a better vendor-splitting.

Multiple page applications

webpack.config.js

const config = {
  entry: {
    pageOne: './src/pageOne/index.js',
    pageTwo: './src/pageTwo/index.js',
    pageThree: './src/pageThree/index.js'
  }
};
Copy the code

What is? We told WebPack that we needed three separate dependency diagrams (as in the example above).

Why is that? In a multi-page application, the server will fetch a new HTML document for you. The page reloads the new document, and the resource is re-downloaded. However, this gives us a special opportunity to do a lot of things:

  • useCommonsChunkPluginCreate bundles for application sharing code between each page. With the increase in entry points, multi-page applications can greatly benefit from these techniques by reusing large amounts of code/modules at entry points.

T> A rule of thumb: use only one entry starting point per HTML document.

Original text: webpack.js.org/concepts/en…