Webpack core concept entry configuration (entry)

If the dependencies of each module in the project are regarded as a tree, then the entry is the root of the dependency tree.

These dependent modules will be encapsulated into a chunk when packaging. So what is chunk?

Chunk literally means code block, which in Webpack can be understood as some modules that have been abstracted and packaged. It is like a file bag containing many files. The files inside are each module. Webpack adds a layer of packaging on the outside to form a chunk:

Depending on the specific configuration, one or more chunks may be generated when a project is packaged.

Multiple entries can be defined in the project, and each entry will generate a result resource.

For example, there are two entries in our project, src/index.js and src/lib.js . Under normal circumstances, dist/index.js and dist/lib.js will be packaged and generated. dist/lib.js .

In some special cases, one entry may generate multiple chunks and ultimately multiple bundle

entries.

Parameters: Entry

• entry is the entrance to the configuration module , which can be abstracted into input. The first step of Webpack's execution of the build will be to search and recursively parse out all entry-dependent modules.
• The entry configuration is required. If not filled in, Webpack will Report an error and exit

module.exports = {
	entry:'./src/index.js', //Indicates the entry file, that is, entering our project from index.js};

①Entry type

If it is an array type, when used with the output.library configuration item, only the last one in the array The module of the entry file will be exported

② Chunk name

Webpack will give a name to each generated Chunk. The name of the Chunk is related to the configuration of the Entry:

• if the entry is a string or array, only one Chunk will be generated. At this time, the name of the Chunk Is main;
• if entry is an object, multiple Chunks may appear. At this time, the name of the Chunk is the name of the key in the object key-value pair.

③Entry configuration dynamics.

If there are multiple pages in the project, you need to configure an entry for each page. Entry, but the number of these pages may continue to grow, then the configuration of Entry will be affected by other factors and cannot be written as a static value. The solution is to set Entry into a function to dynamically return the configuration mentioned above. The code is as follows:

// Synchronous function entry: () => {
  return {
    a:'./pages/a',
    b:'./pages/b',
  }
};
// Asynchronous function entry: () => {
  return new Promise((resolve)=>{
    resolve({
       a:'./pages/a',
       b:'./pages/b',
    });
  });
};

Parameter: context

Webpack will use context as the root directory when looking for files with relative paths . Context defaults to the current working directory where Webpack is started. If you want to change the default configuration of context, you can set it like this in the configuration file:

module.exports = {
	context: path.resolve(__dirname, 'app')
}

Note that context must be an absolute path string.

single entry file configuration

by bringing the parameter webpack --context when starting Webpack.

Usage: entry:string|Array<string>

1. Abbreviated syntax

webpack.config.js

//Since it is single, it can be abbreviated as:
module.exports = {
  entry: './main.js'
};

The above entry configuration is actually written as the following abbreviation

module.exports = {
  entry: {
    main: './main.js'
  }
};

2. Array syntax

module.exports = {
  entry: {
    main:['./main.js','./main2.js']
  }
};

The function of passing in an array is to merge multiple resources in advance. When packaging, Webpack will use the last element in the array as the actual entry path.

When using a string or array to define a single entry, there is no way to change the chunk name. , can only be the default "main".

Multiple entry file configuration

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

Object syntax

module.exports = {
  entry: {
    app: './src/app.js',
    vendors: './src/vendors.js'
  }
};

This will be more cumbersome. However this is the most extensible way of defining entry points in an application.

"Extensible webpack configuration" : reusable and can be combined with other configurations. This is a popular technique for separating concerns from the environment, build target, and runtime. Then merge them using specialized tools like webpack-merge.

Application scenarios

1. Single-page applications

, whether they are frameworks, libraries, or modules on each page, are referenced by a single entry point of app.js The advantage of this is that only one JS file will be generated and the dependencies will be clear .

module.exports = {
  entry: './src/app.js'
};

This approach also has disadvantages, that is, all modules are packaged together. When the scale of the application increases to a certain level, the resource volume generated will be too large, which will reduce the user's page rendering speed

. In the default configuration of Webpack, when a bundle is larger than At 250kB (before compression), the bundle will be considered to be too large, and a warning will occur during packaging, as shown in the figure:

2. Separate the third-party library (vendor).

In order to solve the above problem, you can extract the third-party library (vendor).

Vendor means "supplier". In Webpack, vendor generally refers to third parties such as libraries and frameworks used by the project. Bundle

module.exports = {
  entry: {
    app: './src/app.js',
    vendors: ['react','react-dom','react-router'],
  }
};

Based on the example of application, we added a new entrance with the chunk name of vendor , and put the third-party modules that the project depends on in the form of an array.

We did not set the entry path for the vendor. What should Webpack do? What about packing?

At this time we can use CommonsChunkPlugin (CommonsChunkPlugin has been abandoned after Webpack 4, you can use optimization.splitChunks) to extract the common modules in the two chunks of app and vendor.

With this configuration, the bundle generated by app.js will only contain The business module and the third-party modules it depends on will be extracted to generate a new bundle, which also achieves our goal of extracting the vendor.

Since the vendor only contains third-party modules, this part will not change frequently. Therefore, client-side caching can be effectively utilized, which will speed up the overall rendering speed when the user subsequently requests the page.

CommonsChunkPlugin is mainly used to extract third-party libraries and public modules to prevent bundle files loaded on the first screen or bundle files loaded on demand from being too large, resulting in long loading times.

3. Multi-page application

For multi-page application scenarios, in order to reduce the size of resources as much as possible, we hope that each page only loads its own necessary logic, rather than packaging all pages into the same bundle. Therefore, each page needs an independent bundle . In this case, we use multiple entries to achieve this. Please see the following example:

module.exports = {
  entry: {
    pageOne: './src/pageOne/index.js',
    pageTwo: './src/pageTwo/index.js',
    pageThree: './src/pageThree/index.js'
  }
};

The above configuration tells webpack that it needs 3 independent and separated dependency graphs. At this time, the entry and the page are in one-to-one correspondence, so that each HTML can load the modules it needs as long as it introduces its own JS.