为什么选择 webpack

要了解为什么应该使用 webpack，让我们回顾一下在打包工具出现之前，我们如何在网络上使用 JavaScript。

在浏览器中运行 JavaScript 有两种方式。首先，为每个功能包含一个脚本；这种解决方案难以扩展，因为加载太多脚本可能导致网络瓶颈。第二种选择是使用一个包含所有项目代码的大型 .js 文件，但这会导致作用域、大小、可读性和可维护性方面的问题。

IIFEs - 立即调用函数表达式

IIFEs 解决了大型项目的作用域问题；当脚本文件被 IIFE 包装时，你可以安全地连接或组合文件，而无需担心作用域冲突。

IIFEs 的使用催生了 Make、Gulp、Grunt、Broccoli 或 Brunch 等工具。这些工具被称为任务运行器（task runners），它们将所有项目文件连接在一起。

然而，更改一个文件意味着你必须重新构建整个项目。连接文件使得在文件之间重用脚本变得更容易，但却使得构建优化变得更加困难。你如何判断代码是否实际被使用？

即使你只使用 lodash 中的一个函数，也必须添加整个库并将其压缩在一起。你如何对代码中的依赖项进行摇树优化（treeshake）？大规模地延迟加载代码块可能很困难，并且需要开发人员进行大量的手动工作。

JavaScript 模块的诞生归功于 Node.js

Webpack 运行在 Node.js 上，这是一个 JavaScript 运行时，可以在浏览器环境之外的计算机和服务器中使用。

当 Node.js 发布时，一个新时代开始了，同时也带来了新的挑战。现在 JavaScript 不在浏览器中运行，Node 应用程序应该如何加载新的代码块？没有 HTML 文件和可添加到其中的脚本标签。

CommonJS 问世并引入了 require，它允许你在当前文件中加载和使用模块。通过按需导入每个模块，这解决了开箱即用的作用域问题。

npm + Node.js + 模块 – 大规模分发

JavaScript 正在作为一种语言、一个平台以及一种快速开发和创建应用程序的方式席卷全球。

但浏览器不支持 CommonJS。没有 实时绑定。存在循环引用问题。同步模块解析和加载速度慢。虽然 CommonJS 是 Node.js 项目的一个很好的解决方案，但浏览器不支持模块，因此创建了 Browserify、RequireJS 和 SystemJS 等打包工具，使我们能够编写在浏览器中运行的 CommonJS 模块。

ESM - ECMAScript 模块

对于 Web 项目来说，好消息是模块正在成为 ECMAScript 标准的官方功能。然而，浏览器支持尚不完善，与这些早期的模块实现相比，打包仍然更快，并且目前更受推荐。

自动依赖收集

老式的任务运行器，甚至是 Google Closure Compiler，都要求你预先手动声明所有依赖项。而像 webpack 这样的打包工具则根据导入和导出的内容自动构建并推断你的依赖图。这与其他的插件和加载器一起，带来了极佳的开发体验。

难道不好吗……

……拥有一个不仅能让我们编写模块，还能支持任何模块格式（至少在达到 ESM 之前）并同时处理资源和资产的工具？

这就是 webpack 存在的原因。它是一个工具，允许你打包 JavaScript 应用程序（同时支持 ESM 和 CommonJS），并且可以扩展以支持许多不同的资产，例如图片、字体和样式表。

Webpack 关注性能和加载时间；它总是在改进或添加新功能，例如异步块加载和预取，以提供项目和用户的最佳体验。