Webpack loader:缓存时是否考虑选项? [英] Webpack loaders: Are options considered when caching?

问题描述

我正在编写一个应该可以缓存的 Webpack 加载器.this.cacheable 的文档说:

I'm writing a Webpack loader that should be cacheable. The documentation for this.cacheable says:

当输入和依赖项没有改变时，一个可缓存的加载器必须有一个确定性的结果.

A cacheable loader must have a deterministic result, when inputs and dependencies haven't changed.

现在我想知道:加载器的选项在这个意义上算作输入"吗?

Now I wonder: Do the loader's options count as "input" in this sense?

假设我有一个 Webpack 构建，它在模块上使用带有选项 { foo: 1 } 的加载器.在下一次编译中，它在同一个模块上使用同一个加载器，但带有选项 { foo: 2 }.第一次编译的输出会被重用，还是 Webpack(正确地)意识到加载器的选项已经改变并因此重新加载模块?

Assume I have a Webpack build that uses a loader with options { foo: 1 } on a module. In the next compilation, it uses the same loader on the same module, but with options { foo: 2 }. Will the output from the first compilation be re-used, or will Webpack (correctly) realize that the loader's options have changed and thus re-load the module?

假设 Webpack 确实比较 options 对象，它们是如何比较的?引用?使用深度比较?比较逻辑将决定我可以安全地使用哪些类型的数据作为加载程序选项.

Assuming that Webpack does compare the options objects, how are they compared? By reference? Using a deep comparison? The comparison logic would dictate what types of data I can safely use as loader options.

推荐答案

简短版本:

Webpack 通过其 request 字符串识别模块.该字符串包含文件路径以及所有相关加载器的路径和选项.这实际上意味着更改一个加载器上的选项将导致不同的请求字符串，因此之前的加载结果不会被重用.

Webpack identifies a module via its request string. This string contains the file path as well as the paths and options of all involved loaders. This effectively means that changing the options on one loader will result in a different request string, so the previous load result will not be re-used.

长版:

请求字符串以！"分隔，由 此代码.

Request strings are "!"-separated and are created by this code.

考虑这个请求字符串:

"/Users/wolf/dev/webpack-test/test-loader.js!/Users/wolf/dev/webpack-test/patch-loader.js??ref--0-0!/Users/wolf/dev/webpack-test/src/foo.js"

这意味着(从右到左)文件 /Users/wolf/dev/webpack-test/src/foo.js 将首先使用加载器 /Users/wolf/dev/webpack-test/patch-loader.js 带有选项 ref--0-0，然后加载器 /Users/wolf/dev/webpack-test/test-loader.js 没有任何选项.

This means (from right to left) that file /Users/wolf/dev/webpack-test/src/foo.js is to be loaded using first the loader /Users/wolf/dev/webpack-test/patch-loader.js with options ref--0-0, then the loader /Users/wolf/dev/webpack-test/test-loader.js without any options.

现在的相关问题是 Webpack 在创建请求字符串时如何序列化加载器的选项.可以在此代码中找到答案:

The relevant question, now, is how Webpack serializes the loaders' options when creating the request string. The answer can be found in this code:

让 loaderData 成为这种形式的对象:

Let loaderData be an object of this form:

{
  loader: string, // Path to loader
  options: string | object | null | undefined,
  ident: string | null | undefined
}

• 如果 loaderData.options 是字符串，则按原样使用.
• 否则，如果 loaderData.ident 为真，则使用此值.
• 否则，loaderData.options 使用 JSON.stringify 进行字符串化.
• If loaderData.options is a string, it is used as-is.
• Otherwise, if loaderData.ident is truthy, this value is used.
• Otherwise, loaderData.options is stringified using JSON.stringify.

似乎当加载器被静态指定时，Webpack 知道它们的选项不会改变.所以 RuleSet.normalizeRule() 为它们分配固定的 ident 属性.这就是上面带有 ref--0-0 的示例中发生的情况.

It appears that when loaders are specified statically, Webpack knows that their options won't change. So RuleSet.normalizeRule() assigns them fixed ident properties. This is what happened in the example above with ref--0-0.

这里的一个关键见解是加载器选项应该是相当简单的对象，以便对它们调用 JSON.stringify 不会丢失任何信息.否则，Webpack 可能会无意中重用使用不同加载器选项的缓存结果.或者，您可以将 loaderData.ident 显式设置为唯一标识选项的字符串(例如哈希码).

One key insight here is that loader options should be rather simple objects so that calling JSON.stringify on them doesn't lose any information. Otherwise, Webpack may inadvertently re-use a cached result that used different loader options. Alternatively, you can explicitly set loaderData.ident to a string that uniquely identifies the options (such as a hash code).

这篇关于Webpack loader:缓存时是否考虑选项?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！