preface

Webpack is a heavy topic, there are a lot of articles on how to write configuration, how to write loader, and how to write plugin. Even in order to make fun of the complexity of Webpack configuration, the industry invented a job “WebPack configuration engineer”. How to write configuration, loader, plugin is a kind of “consulting knowledge” in my opinion. When you use it, it’s fast, but when you don’t use it, it’s hard to remember.

However, if the understanding of Webpack only stays at this level, it always feels strange to Webpack, and there is still a layer of invisible veil between webpack.

What is behind this veil? Xiaobian think it should be the macro level of webpack design concept of cognition. Where WebPack came from, what problems to solve, how to solve them, how to evolve in the future, and so on. But if you do a Search on Baidu or Google for “Webpack design concept,” you won’t get much, frankly, at all.

Without data, we try to refine it ourselves, improper or wrong place, welcome message exchange ~

① Why webpack

Visually, WebPack is a far cry from Node.js. However, if we look at the birth of new things in the historical context to which they belong, we will find that there is some wonderful causal relationship between them.

Through the color of the figure above, it can be divided into three ecology. One is the JS modular development route represented by pink. The other is the node.js ecological expansion route represented by orange. The last one is webapck represented by orange.

In Readme.md, webpack’s first submission, we can see the author’s very clear and simple desire:

As developer you want to reuse existing code. As with node.js and web all file are already in the same language, but it is extra work to use your code with the node.js module system and the browser. The goal of webpack is to bundle CommonJs modules into javascript files which can be loaded by <script>-tags.

Paraphrase:

As developers, everyone wants to reuse existing code. Node.js and Web applications use the same language. However, if you want to reuse the Node.js module to the browser, you need to do a lot of extra work. The goal of Webpack is to package CommonJs modules into javascript files that can then be loaded by

From the above, webpack authors see that there is a lot of JS code in the Node.js ecosystem that cannot be reused by browsers. Hence the idea of packaging modular code based on the CommonJS specification into modules that can be loaded by < Script >. So it’s probably not too much of a stretch to say that Webpack originated from Node.js.

② What problem is Webpack trying to solve

If we look at webPack’s official documentation, it has a lot of features. Ts loading, image loading, Sourcemap, code compression, code splitting, hot loading, Treeshaking and more….

Which is the core feature of WebPack? Where exactly is the expansion boundary for WebPack? Will webPack’s capabilities continue to expand indefinitely as versions go through iterations? What is the development thinking behind the author?

The package.json file that I wrote in the first commit is the following:

Bundle CommonJS modules into single script or multiple scripts for web browser.

Paraphrase:

Package JS modules that follow the CommonJS specification into one or more scripts for use by Web browsers.

Meanwhile, there is a clear definition of Webpack on webpack’s official website:

At its core, webpack is a static module bundler for modern JavaScript applications. When webpack processes your application, it internally builds a dependency graph which maps every module your project needs and generates one or more bundles.

Paraphrase:

Webpack is a static module wrapper for modern JS applications. When WebPack processes your application, it creates a dependency map for all the modules in the project and packs it into one or more packages.

In the end, this timeless sketch on the Webpack website says it all.

From the beginning of WebPack to the current 5.x release, the original concept has remained the same: bundle.

It’s just that as the front-end technology ecosystem continues to evolve and flourish, there are a lot of new twists: TS, VUE, ELECTRON, ES6, etc. In response to these new trends, the Webpack ecosystem continues to evolve and expand. But, again, no matter how WebPack grows and expands, the original focus has always been on “packaging”. To make packing easier and more comfortable, of course. Webpack incidentally addresses many of the small peripheral features needed for “packaging.” Examples include code splitting, loading on demand, CDN acceleration, Treeshaking, and more.

③ How does Webpack solve the problem of “packaging”

Imagine if we were to design a “packaging tool” for the browser.

First of all, we have to find a way to convert vUE, TS and other files that the browser cannot recognize directly into js files that can be recognized. In addition, if a VUE, TS module references other modules, find a way to analyze their dependencies and package them together.

Finally, consider that wrapping all dependent modules in a single file may be slow for network requests, and you need to figure out how to do that.

In fact, thinking of the above three points, you can already touch the design soul of Webpack. In the initial design of Webpack, the author needs to solve the core problems, in fact, are basically the above three points. However, the difference between ordinary people and great gods is that ordinary people just think. However, God can provide a perfect and time-tested architectural solution to the above problems.

In order to solve the above three problems. First, webpack author put forward a concept of “Everything module”. Whether it is JS code files, or various image resources, they are finally grouped together with the concept of “Module”. Through the concept of “module”, the author draws all kinds of complicated and chaotic file types to an equal relation axis.

Secondly, the author of Webpack designed the following four concepts: Entry, Output, Loaders and Plugins to achieve a clear structure, open function and continuous iterative architecture design for Webpack.

These are concepts that we often encounter when configuring WebPack. But often only the blind men feel the elephant, its part, but not the whole. To deepen our understanding of these four concepts as a whole, let’s draw another diagram that illustrates the design ideas of the webpack authors.

From the picture above, we can see that:

• Webpack uses the Entry concept to solve the “Entry” problem of analysis;
• Solve “dependency graph building” problem with Loaders concept, translate all kinds of weird file types;
• Opening up the WebPack runtime to the outside world with Plugins so that third-party developers can extend the functionality of WebPack;
• The concept of Output covers all “Output” problems.

Also, because Plugins and Loaders are open designs, webPack has continued flexibility. If there’s one thing to say about webPack’s architectural design, it’s simple and vibrant.

④ In addition to “packaging”, what other capabilities webpack has

If “packaging” is the first core webPack capability, then “unpacking (code splitting)” is the second core WebPack capability. In fact, this reason is easy to understand. “Package” and “unpack (code split)” are symbiotic, and if WebPack only focuses on “package”, the resulting “package” may be too bulky to be useful.

In addition to “code splitting,” common peripherals in the WebPack ecosystem are summarized as follows:

⑤ Finally, let’s talk about the so-called competitors of Webpack

If we have a deeper understanding of why WebPack exists and what problems WebPack solves, we will see that there is no such thing as a “rival” to popular software.

• webpack

The product is positioned as a module packer that combines Node.js with browser-side JS code resources. Although webPack’s loader and plugin capabilities now make it seem omnipotent, WebPack’s position as a module packer has not changed. It looks powerful, just an added benefit of WebPack’s open design.

• Grunt

Is a task executor. There are a number of plug-ins that encapsulate common tasks, manage dependencies between tasks and automate dependent tasks.

• Gulp

Is a flow-based task manager.

summary

Webapck is essentially a module packer. Because of its open design, it can do some of the work of building tools. The Grunt is the pure tasker; Gulp is positioned as a build tool.

Well, WebPack stumbled into the target territory of other products. But the purpose of Webapck remains the same. Finally, consider this quote from the Webpack website:

At its core, webpack is a static module bundler for modern JavaScript applications.