blog
blog copied to clipboard
lmk123
使用 gulp-rev-all 来解决 RequireJS 的增量更新问题
这两天陆续学习了下 gulp 与 f.i.s。学习 gulp 纯粹是好奇它为什么会比 grunt 流行（我的结论在 #3），而学习 fis 则是为了解决一个_“前端工程”_问题。
我基于一些原因（见 #2），在公司项目里使用了 RequireJS，但我仍需要解决它的增量更新问题。单靠 RequireJS 提供的 urlArgs 是远远不够的，最好的办法应该是这篇文章里所说的那样，给每个静态文件的文件名加上 md5。
在我思考要不要脱离 fis、自己来实现的时候，我在网上搜到了一个 gulp 插件：gulp-rev-all。比起 fis 那种通过更新 RequireJS 中的 paths 设置，这个插件做的事情更符合我的意愿。它能把下面的代码：
requrie(['libs/doT'],function (d) {
// ...
});
转换成：
requrie(['libs/doT.dfe5trf3'],function (d) {
// ...
});
也就是说，它在给所有文件添加 hash 的同时，还会更改引用过这些文件的地方，无论是 css 里面的图片，还是 js 里面引用的模块：这样就不需要额外加载映射表了。毕竟随着项目的增长，映射表可能会变得越来越庞大。
真是踏破铁鞋无觅处，得来全不费工夫。- -
这种方式仍然有需要注意的地方：如果项目是前后端分离的，那么服务端的模板里面不应该有调用 requrie(['deps']) 的 inline script；如果不是，那就将后端模板也纳入插件的处理范围，当然这样做有点……怎么说呢，low。
那么，关于前端工程的研究总算能告一段落了。最好能做一个 demo 出来。
@simongfxu 我在这个项目里用了 requirejs + gulp-rev-all，gh-pages 分支里就是加过 md5 之后的文件。你看看 gulpfile.js 就大致了解该怎么用了。希望还不算迟。- -
thanks，有空看下。
我后来用自己的方法实现了，没有使用gulp或者grunt等，就是自己写脚本配合r.js强大的功能。
本质还是维护映射表，但是这个映射表不会变的很大。因为个人觉得一个项目脚本数目最多的肯定还是业务类，现在我习惯于把所有的业务脚本合并打包压缩。最后我发现就算我的业务量增加到目前的八倍左右，我的业务脚本刚好和我使用的第三方基础库的大小一样（合并后）。
再加上上周刚刚把业务类的组件封装了一遍（之前写的都是通用组件），发现业务类脚本代码量又可以减少三分之一到二分之一，感谢MVVM！
urlArgs也是可以的。之前用requirejs的时候也是为了解决增量更新的问题折腾了好一翻，那时没发现有gulp-rev-all，最后的解决方案是修改requirejs的源码，把urlArgs改成一个function。最终结果肯定是没有修改文件名那样完美，也是一种可行的选择。具体可看下我之前写的文章。http://segmentfault.com/a/1190000000761578
@hellopao 你看到你这篇文章第一条（或者说唯一的那条）评论没有？那就是我留下的 :) 我很早就看过了，只是我个人不太喜欢修改第三方脚本的源码，所以没有采用 :)
使用 gulp-rev-all 确实可以递归查找以来并计算 hash 值。但也存在风险，比如公共部分的模块修改了，因为递归查找以来并计算 hash 的原理，会导致几乎全局的 js 的 hash 会重新计算一遍。在这种情况下达不到增量更新的效果。觉得使用 paths 来说可能会更加合理一些。当然由于频繁更新的问题，会导致资源映射表也常常更新，我觉得可以将这部分两大块，一部分是不常更新的列表，一部分是经常变动的~~
Webpack 既支持按需加载，又支持根据内容将文件重命名为 hash，不需要有思路，简单的配置一下就可以了：
Code Splitting（按需加载） Long-term Caching（hash 文件名）