Grunt filerev、usemin 和文件缓存

Question

我正在使用 grunt filerev 任务在文件内容更改时将缓存清除器添加到文件中。 usemin 任务将相关文件路径替换为其引用的修订版本。一切都设置得很好，它们按预期/在他们的文档中写的那样工作。

我现在试着解释一下这个问题：

这是一个 Angular JS 项目，其简化结构有点像这样：

a.html -> b.js -> c.html (partial)

这里 a.html 指的是 b.js，b.js 将 c.html 作为部分加载。服务器设置为缓存所有这些资产，因此 cachebuster 字符串变得很重要。

当我运行grunt build 以执行filerev 然后usemin 时，它将c.html 重命名为c.[md5_hash_of_c].html，b.js 重命名为b.[md5_hash_of_b].js 和a.html 重命名为a.[md5_hash_of_a].html。在此之后，它将b.js 中c.html 的参考线更新为c.[md5_hash_of_c].html。同样，它也会更新a.html。这意味着在计算哈希时，这些文件仍然引用了其他文件的未修订版本。因此，当c.html 的内容发生更改时，它会更新其在b.js 中的引用，但不会更新b.js 的名称以反映此更改。

这违背了在文件名中获取缓存破坏者的目的。因为现在浏览器缓存了b.[md5_hash_of_b].js 和a.[md5_hahs_of_a].html，所以调用更新的c.[md5_hash_of_c].html 失败。

我在想，在 Angular 世界和其他地方，这应该是一种非常标准的做法，但在任何地方都看不到它的详细讨论。我正在寻找可以解决此问题的工作流程。

Answer 1

在threedifferentplaces 上发现了这个问题。第三个链接最接近解决方案。

我最终使用vermin 作为filerev 和usemin 的替换任务，它在内部重复执行这两个任务，直到文件名停止更改。在这里分享一个要点：https://gist.github.com/markrian/aa185c5ec66232a38a68

来自 gist cmets：

/**
 * Vermin completely manages the running of the filerev and usemin tasks, so
 * that assets that reference other assets are correctly hashed after their
 * referenced assets are spliced in by usemin.
 *
 * Vermin also makes various assumptions about how filerev and usemin are set
 * up. For instance, it assumes that usemin runs immediately after filerev,
 * that filerev renames files in-place, and that usemin relies on
 * `grunt.filerev.summary`, as prepared by filerev (which vermin manipulates).
 * There may be other implicit assumptions that haven't been identified yet.
 *
 * Because grunt tasks can only be inserted into the task stack, to be run
 * sequentially, vermin recursively adds filerev, usemin and itself to the
 * stack to do its work. It maintains its state on the grunt object, and reads
 * that on each run to determine where in the process it is.
 */