Why do YOU need a packaging tool?

Many people’s first impression of Webpack will be “packaging tools.”

So why does the front end need a packaging tool?

What were the problems with front-end development before packaging tools?

Do we really need packing tools?

With the development of the Internet, front-end projects become more and more complex. At the same time, V8 engine also enables JavaScript, a toy language, to plug in the wings of commercial project development, so that JS is no longer constrained by the browser environment, and begins to enter the field of system-level development.

As the complexity of a project increases, the code specification and management must be synchronized. Therefore, various modular specifications have been proposed in the programming community. CommonJS specification is selected for the server and AMD specification is selected for the client. However, there are some problems in the two modular specifications. They are both JS programming and have two different modularity specifications, which are not enough at the JS language level.

Finally, in ES6, the ECMA Committee introduced a language-level module system: the ESModules specification.

In the current programming practice, front-end programming benefits from the development of building tools, the coding process using ESModules specification is very widespread, but the back-end is still using CommonJS specification more, but NodeJS has made changes, gradually tend to ESModules specification.

Let’s take a quick look at the syntactic features of ES Modules with a little code.

Modularization can help us better solve the problem of code organization in the process of complex application development, but with the introduction of modularization, some new problems will arise in our front-end application, such as:

First of all, the ES Modules system we use has its own environmental compatibility problems. Although the latest versions of major browsers support this feature, there is no guarantee that users will use it. So we also need to solve the compatibility problem.

Secondly, the modular way is divided into too many module files, and the front-end application is running in the browser, each file needs to be individually requested from the server back. Scattered module files will inevitably lead to frequent network requests from the browser, affecting application efficiency.

Finally, talk about the divergence on the basis of implementing JS modularization. With the increasing complexity of applications, it is not only JavaScript code that needs to be modularized, but also HTML and CSS resource files that need to be modularized during front-end application development. And from a macro point of view, these files should also be considered modules in the front-end application, but these modules have different types and uses than JavaScript.

Modularization is definitely necessary for the development process, so we need to put it on the front modular implementation based on the introduction of better scheme or tool, to solve the above three questions, let us in the development stage of the application of continue to enjoy the advantages of modular and don’t have to worry about the impact of modularization on the production environment.

As you can imagine, this is where Webpack and other packaging tools come in, and the above question is at the heart of what these tools are designed to solve.

In essence, Webpack is a static Module bundler for modern JavaScript applications.

Core principles of Webpack

Let’s take a look at how Webpack works and how it works at its core.

In fact, the hero area on the first screen of Webpack’s official website clearly describes how it works, as shown below:

Take a typical front-end project, which is littered with a variety of code and resource files, as shown below:

JS, CSS, images, fonts, etc., all belong to a module in the current project in the mind of Webpack. Webpack can be packaged to eventually bring them together.

Webpack throughout the packaging process:

  • The Loader processes the loading of special types of resources, such as loading styles and images.

  • The Plugin enables various automated build tasks, such as automatic compression and automatic publishing.

Look at the packaging process.

Once Webpack starts, it finds a specified file in the project (usually a JS file) as the entry point, based on our configuration. Then follow the code in the entry file, according to the occurrence of the code import (ES Modules) or require (CommonJS) statements, parse and infer the resource module that the file depends on. Then the dependencies of each resource module are analyzed separately, and the whole process is repeated. Finally, a dependency tree is formed between all the files used in the whole project.

The following animation vividly demonstrates this process:

Once you have the dependency tree, Webpack iterates (recursively) through the dependency tree to find the resource file for each node. Then give the module to the corresponding Loader according to the Loader configuration in the configuration option. Finally, you can package the entire project by putting the loaded results into bundle.js.

For specific operations, please refer to the following animation:

For resource modules that cannot be represented by JavaScript codes in dependent modules, such as images or font files, loaders generally copy them as resource files to the output directory, and then expose the access path corresponding to the resource file as the exported member of this module.

Loader mechanism plays an important role in the whole packaging process. Because without Loader, Webpack can’t load various types of resource files, so Webpack is just a tool for merging JS module code.

Now you know the core working process of Webpack.

As for the plug-in mechanism, in order to provide a powerful extension capability, Webpack prefabricated a hook for each link of the whole working process, which does not affect the core working process of Webpack, that is to say, we can implant some custom tasks into any link of the Working process of Webpack through the plug-in. This extends the capabilities of Webpack beyond its packaging capabilities.