Webpack:Webpack 内部是如何工作的? [关闭]

2023-12-28

据我所知,Webpack 是一个用于组织项目中资产的工具。不过,我不明白它内部是如何工作的,看起来有点神奇。

  • 是否有某种运行时引擎来解析模块或依赖项?
  • Does it run on the server or in the client browser?
    • 如果它在服务器上运行,它是否必须在某种类型上运行webpack-*-server?
    • 如果它在浏览器中运行,它如何构建 module loader map?它是如何发送到浏览器的?

Webpack - 原因和方法

不要让自己对 Webpack 所做的所有花哨的东西感到困惑。 那什么是Webpack呢?嗯,它是一个模块捆绑器,我们开始吧。开个玩笑,这对初学者来说根本没有什么意义。我相信为什么很重要gettingwebpack 因此这个答案的大部分内容将集中于此。

Webpack 的核心允许我们在浏览器中使用 javascript 模块,方法是获取多个文件和资产并将它们组合成一个大文件,如下图所示,来自新文档:网页包2 https://webpack.js.org/.

所有额外的闪亮的东西,例如将 es6/7 编译为 es5 或允许我们使用 css 模块都很好extras由 Webpack 提供给我们。

Webpack 插件和附加功能的强大生态系统使 Webpack 看起来很混乱,因为它看起来做了很多事情。虽然通过插件为我们提供的附加功能很棒,但我们需要继续关注 Webpack 存在的核心原因 -模块捆绑。因此,加载器和插件不属于 Webpack 帮助解决的基本问题的高级讨论范围。

Webpack 是一个用于创建资源包(代码和文件)的命令行工具。 Webpack 不在服务器或浏览器上运行。 Webpack 会获取所有 javascript 文件和任何其他资源,然后将其转换为一个大文件。

然后服务器可以将这个大文件发送到客户端的浏览器。 请记住,浏览器和服务器并不关心这个大文件是使用 Webpack 生成的,它只是像对待任何其他文件一样对待它。

webpack-dev-server 与 webpack cli

webpack-dev-server 是一个与 webpack cli 根本不同的工具(命令行工具)如上所述。它是一个运行在node/express上的开发服务器。当该服务器运行时,我们从该开发服务器上的一个端口加载我们的应用程序,并且我们可以在开发应用程序时访问其他功能,这使我们的生活更轻松,例如热模块重新加载和自动捆绑(运行 webpack cli 以在文件时自动捆绑)变化)。热模块重新加载的优点是我们可以保持应用程序运行并注入在运行时编辑的文件的新版本。因此,我们可以看到应用程序中某些文件的变化,而不会丢失整个应用程序的状态。

The Why

传统服务器渲染应用程序

传统上,应用程序是在服务器端渲染的。这意味着请求是由客户端向服务器发出的,所有逻辑都在服务器上。服务器将静态 html 页面返回给客户端,这就是客户端在浏览器中看到的内容。这就是为什么每当您在旧的服务器端渲染应用程序中导航时,您都会看到页面刷新时闪烁。

单页应用程序 - SPA

然而,如今单页应用程序非常流行。在单页应用程序上,我们的应用程序在一个 url 内打开窗口,我们永远不需要刷新。这对于用户来说被认为是更好的体验,因为无需刷新就感觉更流畅。在 SPA 中,如果我们想从主页导航到登录页面,我们将导航到登录页面的 URL。然而,与传统的服务器端渲染页面不同,当客户端浏览器发出此请求时,页面将不会刷新。相反,应用程序将动态更新自身以显示登录内容。尽管这看起来像我们的单页应用程序中的单独页面,但我们的应用程序只是动态更新不同的页面。

动态 SPA 意味着浏览器中包含更多代码

因此,在具有所有这些动态内容的 SPA 中,浏览器中存在更多的 javascript 代码。当我们说动态时,我们指的是以 JavaScript 形式存在于客户端浏览器中的逻辑量。我们的服务器端渲染应用程序会输出非动态的静态页面。动态性全部发生在服务器中,同时生成静态页面,但一旦到达浏览器,它就相对静态(其中没有很多 JavaScript)

The How

管理新的丰富的浏览器逻辑,即更多的 Javascript

Webpack 的主要设计目的是应对客户端中越来越多的 javascript 的新兴趋势。

好吧,那么我们的浏览器中有很多 JavaScript,为什么这是一个问题呢?

我们需要将代码拆分为客户端上的多个文件,以便应用程序更易于使用

那么,我们把它们放在哪里呢?我们可以将所有内容放在一个大文件中。然而,如果我们这样做,那么费力地浏览它并了解所有部分是如何工作的将是一场噩梦。相反,我们需要根据每个块的功能将这一大块代码分割成更小的块——即将代码分割到多个文件中。

您可能知道,当我们谈论“使某些东西模块化”时,我们的意思是将大事物分解为按功能分组的小事物。您可能会想为什么不将大块代码分成小块并完成它。问题是客户端无法神奇地知道哪些文件从其他文件导入内容。所以我们可以在没有 Webpack 的情况下拥有多个独立的文件,但是该应用程序将无法正常工作,因为在大块代码中,它的大部分代码很可能依赖于大块代码中的其他部分来工作.

我们需要像 Webpack 或其替代方案之一(browserify)来创建模块系统。在服务器端,Node 有一个内置的模块解析器,您可以在其中“请求”模块。然而浏览器不具备此功能。

但是,如果我们有多个文件,有些文件会相互导入,我们需要一种方法来了解哪些文件依赖或依赖哪些文件依赖的彼此身上。 Webpack 允许我们通过遍历文件来在前端使用 JavaScript 模块入口点然后映射它们的依赖关系。将入口点视为相互依赖的文件链中层次结构的顶部。

Webpack 中的模块/依赖解析

通过绘制依赖关系图,Webpack 能够以正确的顺序异步并行加载不同的模块。 Webpack 内部有自己的解析器,用于计算不同模块之间的依赖关系图。 webpack 文档指出

解析器帮助 webpack 找到需要的模块代码 包含在每个此类 require/import 语句的捆绑包中。

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

解决过程非常简单,区分了三个 请求类型:

  • 绝对路径: require("/home/me/file"), require("C:\Home\me\file")
  • 相对路径: require("../src/file"), require("./file") 模块路径:
  • 要求(“模块”),要求(“模块/库/文件”)
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)

Webpack:Webpack 内部是如何工作的? [关闭] 的相关文章

随机推荐