javascript - Rails 5.2+：为什么仍然使用带有 webpacker 的资产管道？

Question

我正在阅读Rails webpacker gem 文档，其中说：

Webpacker 使得使用 JavaScript 预处理器和打包器 webpack 4.x.x+ 来管理 Rails 中类似应用程序的 JavaScript 变得很容易。它与资产管道共存，因为 webpack 的主要目的是类似于应用程序的 JavaScript，而不是图像、CSS 甚至 JavaScript Sprinkles（所有这些都继续存在于应用程序/资产中）。

但是，也可以将 Webpacker 用于 CSS、图像和字体资产，在这种情况下，您甚至可能不需要资产管道。当专门使用基于组件的 JavaScript 框架时，这主要是相关的。

如果 webpacker 能够处理所有这些，我试图了解使用 CSS/images/JS-sprinkles 的旧资产管道背后的基本原理？

我已经阅读了一些其他文章，这些文章引导我使用 webpacker 完成所有这些操作，但我不明白这个决定背后的原因。

这是否只是为了支持遗留应用程序，最终旧资产管道将消失，而 webpacker 将用于 Rails 应用程序中的所有内容？

标签： javascriptruby-on-railswebpack

Answer 1

作为 Webpacker 之前存在的应用程序的维护者，我可以给你一个理由：

很难将现有的前端从 Sprockets 迁移到 Webpack。

Sprockets 将所有 JS 构建到一个具有共享范围的大文件中。Webpack 隔离了每个 JS 模块的范围。要迁移到 Webpack，您需要确保您的代码仍然适用于范围隔离。

这通常是有问题的，因为在 Sprockets 时代，您也没有适当的 JS 要求，并且不得不依赖全局变量或顶级范围变量在 JS 源文件之间共享代码和数据。

Rails 没有提供从 Sprockets 编译到 Webpack 的无痛转换路径。因此，它必须同时支持两者。

但是要回答您的另一个问题 - 继续前进，如果您有足够的 JS 使其值得，您应该使用 Webpacker 。

如果你的前端很简单，如果你使用 Sprockets，你会跳过一些 JS 麻烦。就像你想在你的应用程序中添加 10 行 JS 一样，你可能不想使用依赖管理node_modules等设置一个完整的 JS 环境——这就是使用 Webpack/Webpacker 的代价。如果您只想编译 CSS 并将摘要添加到您的图像文件名中，那么管理 JS 环境将更加没有意义——Sprockets 完全可以做到这一点，而无需package.json任何与 JS 相关的东西。

因此，还有第二个原因：

Webpacker 适用于具有重要前端代码库的应用程序。Sprockets 非常适合向传统的服务器渲染应用程序添加一些 JavaScript，以及完全没有 JavaScript 的应用程序。