javascript - rails 5.2+ : why still use assets pipeline with webpacker?

Question

我正在阅读 Rails webpacker gem documentation它说:

Webpacker makes it easy to use the JavaScript pre-processor and bundler webpack 4.x.x+ to manage application-like JavaScript in Rails. It coexists with the asset pipeline, as the primary purpose for webpack is app-like JavaScript, not images, CSS, or even JavaScript Sprinkles (that all continues to live in app/assets).

However, it is possible to use Webpacker for CSS, images and fonts assets as well, in which case you may not even need the asset pipeline. This is mostly relevant when exclusively using component-based JavaScript frameworks.

我试图了解使用 背后的基本原理两个如果 webpacker 能够处理所有这些，CSS/images/JS-sprinkles 的旧 Assets 管道？
我已经阅读了一些其他文章，这些文章引导我使用 webpacker 完成所有这些操作，但我不明白这个决定背后的原因。
这是否只是为了支持遗留应用程序，最终旧 Assets 管道将消失，而 webpacker 将用于 Rails 应用程序中的所有内容？

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 的应用程序。