Webpack:Webpack 内部是如何工作的？

Question

关闭。这个问题需要更多focused .它目前不接受答案。












想改善这个问题吗？更新问题，使其仅关注一个问题 editing this post .

4年前关闭。




Improve this question




据我了解，Webpack 是一个用于组织项目中 Assets 的工具。但是，我不明白它内部是如何工作的，看起来有点神奇。

是否有某种运行时引擎解析模块或依赖项？

它是在服务器上运行还是在客户端浏览器中运行？

如果它在服务器上运行，它是否必须在某种 webpack-*-server 上运行？ ?

如果它在浏览器中运行，它如何构建模块 <-> 加载器 <-> 映射？它是如何发送到浏览器的？

Answer 1

Webpack - 为什么和如何做
不要让自己被 Webpack 所做的所有花哨的东西弄糊涂了。
那么什么是 Webpack？好吧，它是一个模块捆绑器，我们开始了。开个玩笑，这根本不会告诉初学者。我相信为什么对于获得 webpack 很重要，所以这个答案的大部分将集中在这个上。
Webpack 的核心允许我们在浏览器中使用 javascript 模块，方法是将多个文件和 Assets 组合成一个大文件，如下图所示，来自 Webpack 2 的新文档。 .

所有额外的 Shiny 东西，比如将 es6/7 编译为 es5 或允许我们使用 css 模块，都是 Webpack 提供给我们的很好的额外功能。
Webpack 插件和附加功能的强大生态系统使 Webpack 看起来很困惑，因为它似乎做了很多事情。虽然通过插件提供给我们的附加功能很棒，但我们需要专注于 Webpack 存在的核心原因——模块捆绑。因此，加载器和插件超出了关于 Webpack 帮助解决的基本问题的高级讨论的范围。
Webpack 是一个命令行工具，用于创建 Assets 包(代码和文件)。 Webpack 不在服务器或浏览器上运行。 Webpack 获取您所有的 javascript 文件和任何其他 Assets ，然后将其转换为一个巨大的文件。
这个大文件然后可以由服务器发送到客户端的浏览器。
请记住，浏览器和服务器并不关心这个大文件是使用 Webpack 生成的，它只是像对待任何其他文件一样对待它。
webpack-dev-server 与 webpack cli
webpack-dev-server 是一个与上述 webpack cli(命令行工具)根本不同的工具。它是一个运行在 node/express 上的开发服务器。当这个服务器运行时，我们从这个开发服务器上的一个端口加载我们的应用程序，我们可以在开发我们的应用程序时访问其他功能，使我们的生活更轻松，例如热模块重新加载和自动捆绑(运行 webpack cli 以自动捆绑一个文件变化)。热模块重新加载的优点是我们可以保持应用程序运行并注入(inject)在运行时编辑的文件的新版本。因此，我们可以在不丢失整个应用程序状态的情况下查看应用程序中某些文件的更改。
为什么
传统服务器渲染应用
传统上，应用程序已在服务器端呈现。这意味着客户端向服务器发出请求，并且所有逻辑都在服务器上。服务器向客户端吐出一个静态 html 页面，这就是他们在浏览器中看到的内容。这就是为什么每当您在旧的服务器端渲染应用程序中导航时，您都会看到页面在刷新时闪烁。
单页应用程序 - SPA
然而，如今单页应用程序风靡一时。在单页应用程序中，我们的应用程序在一个 url 中窗口化，我们永远不需要刷新。对于用户来说，这被认为是一种更好的体验，因为它无需刷新就感觉更流畅。在 SPA 中，如果我们想从主页导航到登录页面，我们将导航到登录页面的 url。然而，与传统的服务器端呈现的页面不同，当客户端的浏览器发出此请求时，页面不会刷新。相反，应用程序将动态更新自身以显示登录内容。尽管这在我们的单页应用程序中看起来像一个单独的页面，但我们的应用程序只是针对不同的页面动态更新。
动态 SPA 意味着浏览器中的代码更多
因此，在具有所有这些动态内容的 SPA 中，浏览器中有更多的 javascript 代码。当我们说动态时，我们指的是以 javascript 形式存在于客户端浏览器中的逻辑量。我们的服务器端呈现的应用程序会吐出非动态的静态页面。在生成静态页面时，所有动态都发生在服务器中，但是一旦它访问浏览器，它就相对静态(其中没有很多 javascript)
方法
管理这种新的丰富的浏览器逻辑，即更多的 Javascript
Webpack 的主要目的是应对客户端中越来越多的 javascript 的新兴趋势。
好的，那么我们在浏览器中有很多 javascript 为什么这是一个问题？
我们需要在客户端将代码拆分为多个文件，以便应用程序更易于在 上工作
好吧，我们把它放在哪里？我们可以把它全部放在一个大文件中。但是，如果我们这样做，那么深入了解所有部分的工作原理将是一场噩梦。相反，我们需要根据每个块的功能将这一大块代码拆分成更小的块——即将代码拆分到多个文件中。
正如您可能知道的那样，当我们谈论“制作模块化的东西”时，将大事物分解为按功能分组的较小事物。您可能会想，为什么不将大块代码拆分成小块并完成它。问题是客户端并不神奇地知道哪些文件从其他文件中导入了东西。所以我们可以在没有 Webpack 的情况下有多个隔离的文件，但是 应用程序将无法正常工作，因为它很可能在大块代码中的大部分代码将依赖大块中的其他代码部分来工作 .
我们需要像 Webpack 或它的替代品之一(浏览器)来创建模块系统。 在服务器端，Node 有一个内置的模块解析器，您可以在其中“要求”模块。但是浏览器没有这个功能。
但是，如果我们有多个文件，有些文件会相互导入，我们需要一种方法来知道哪些文件依赖或是 受抚养人 对彼此。 Webpack 允许我们通过遍历来自 的文件在前端使用 JavaScript 模块。入口点 然后映射它们的依赖关系。 将入口点视为相互依赖的文件链中层次结构的顶部。
Webpack 中的模块/依赖解析
通过绘制依赖关系图，Webpack 能够以正确的顺序异步和并行加载不同的模块。 Webpack 内部有自己的解析器，用于计算不同模块之间的依赖关系图。 webpack 文档指出

The resolver helps webpack finds the module code that needs to beincluded in the bundle for every such require/import statement.

然后文档解释了解析器根据 Webpack 捆绑的文件中的导入引用的路径类型采用不同的方法。

The resolving process is pretty simple and distinguishes between threetypes of requests:

• absolute path: require("/home/me/file"), require("C:\Home\me\file")
• relative path: require("../src/file"), require("./file") module path:
• require("module"), require("module/lib/file")