zmNgFrameWork 架构升级ng1.5和md5静态资源缓存方案【angular1.x

　　在我前面的博客，? 把我开发angular的架构进行了分享，并上传到了github??。

而后我又在我的??里分享了??，也更新了github上gulpStart的rev分支??。

　　最近我在更新这个项目，把angular1.4.7更新到了1.5.5，关于angular的升级，我想说性能方面有提升，载入速度和流畅度都得到了提升。

比较坑的一点，我似乎安装错包了，之前的路由hash是用#，升级之后变成了#!，甚至控制台会报一些不影响任何功能的错误。

我打开angular.min.js，发现里面version显示的是 1.5.5-build.4567。于是我又重新bower安装了1.5.5，

版本注释信息才变成了version:1.5.5。这个时候路由hash才是正常的#，之前的报错也不存在了。

　　毕竟还是1.x，升级之后并没有需要修改代码什么的，api是兼容的。关于升级1.5.5就说到这里。

　　升级后，我把zmNgFrameWork?分为三个分支1.4.7、1.5.5 、1.5.5&md5-cache。如果需要md5方案，可以用1.5.5&md50cache这个分支。

　　md5的缓存部署是现在比较合适和流行的解决方案。根据目前项目和架构，我觉得可以在zmNgFrameWork引入此项配置。

项目中的构建工具，我使用的是gulp，gulp-rev就是解决当前问题的插件。

gulp-rev的基本用法这里我就不做过多介绍，需要了解的可以先看这篇文章??。

　　升级前，再啰嗦一下，我们最终需要达到什么效果（以下截图使用gulpStart里的实例）：

如图可以看出

最终build的css和js后缀都带有md5签名，rev.json是存储文件名路径的。

最终html里的文件名路径要和build同步

要实现一键gulp就把这一切事情做好，就需要我们来配置它：

　　 首先还是在zmNgFrameWork?npm安装依赖gulp插件：

　　gulp-rev 来实现

　　gulp-rev-collector 实现

先配置gulp的css任务，打开less.js

require gulp-rev，并加入方框内的代码。

执行在gulp.dest之前，这样输出的文件将会带上md5签名，

如此一来? 就完成了

??

　　新建rev-collector任务，配置好revJson的文件夹路径和html路径，执行这个任务的时候，gulp会找到所有rev.json，与html里的路径匹配，最终就完成了?

　　对，这篇文章不是教大家怎么使用gulp-rev的~ 以上只是简单介绍配置less并大致回顾一下。

　　我们再来回顾一下，zmNgFrameWork?的架构：

　　单页面应用，目前只有一个入口，根目录的index.html

　　src：

　　　　common 包含主要的less（三方库、抽象层和通用样式)，所有图片，和一部分js工具

　　　　modules 所有模块，模块层的less样式，模块的template，模块的控制器、服务和指令

　　　　主模块app.js 将会依赖注入所有 modules 文件夹的子模块

　 build：

　　　　所有图片会被打包到build->common->img，所有css样式最终打包为一个css，被index引用

　　　　模块的所有控制器、服务和指令打包为一个js，被index引用

　　　　主模块app.js，被index引用

　　配置md5缓存部署方案，将会让build里所有js和css加上md5签名，并且更新到index.html中。

根据之前的配置，css已经Ok了，如下图：

　　gulp的时候新建了一个临时输出文件build：temp-build，最开始我其实是直接把rev文件夹放在build文件夹里的，

后来觉得build里面的所有文件都应该是用来部署的静态资源，不需要这些预编译的临时文件。

所以就创建了temp-build作为预编译文件的临时存储。

　　做到这一步其实还算顺利，而后我开始配置js的md5。

在配置过程中，按照之前的写法，我发现gulp会出现报错。

　　报错的意思是当前管道流不支持。我想这是gulp-rev 不兼容browserify的管道的原因。

而后我用一个新任务rev-js，把browserify打包好的js，载入到gulp管道，再执行一次输入输出，就能成功生成md5签名了。

但是这个时候build里面会变成这样：

build里面会存在browserify执行后的无签名的js和md5签名的js。

不应该在build里面有预编译文件，于是也同样把browserify生成的js放到临时文件夹里去。

好了 一切OK。现在?

步骤 ① ?

现在?全部完成。

　　看起来很简单嘛~但是过程还有有点曲折。

特别有一件曲折的事情，我已经同步处理了gulp任务执行顺序，使用gulp-sync

rev-js要操作browserify生成的文件，所以要执行在browserify之后，下图是cmd下gulp执行的日志：

rev-js确实是执行在browserify之后，但是我发现rev-js并没有输出任何东西。

当我执行完gulp default之后，rev-js像是没有运行一样，什么也没输出。

而后我再单独运行一下rev-js任务，这个时候就有输出了（因为这个时候browserify已经完全执行完毕）！

　　后来纠结了很久，又遇到了各种情况，又发生了各种猜测和验证实验。最终的结论确是：

gulp-aync无法获取browserify的管道，也无法得知它的任务是否完成。之所以gulp日志里面显示的是完成，不过是gulp默认的处理而已。

而后，我给rev-js任务加上了延迟，rev-js延迟之后，还需要给rec-collector延迟，rev-collector依赖rev-js。这样才勉强能完成工作。

暂时没有想到更好的办法了。加上延迟之后，gulp-aync无法正确判断它是否完成了任务，所以也会默认处理为完成。

不过这里这样使用暂时不会造成其他问题，这种处理方式实在不优雅。

当然我也想过在browserify任务里，添加监听事件，但是根据目前里面的逻辑，我觉得最好不要那么做。

如果能使node的pipe同步就好了，可以吗？好像不行~求大牛指点！！

小结：

zmNgFrameWork?运行后的样子，两个测试页面：

gulp问题已经解决：

　　browserify同步问题已经得到解决，由下面评论的 @心成 解决的。如他所说，我确实没有返回数据流，through2也帮我解决了browserify循环bundle的问题，总之非常感谢。

而后我还得知，他一年前gulp入门是看我博客入门的，而如今他已经帮我解决了问题了。得多向他学习。。自己都落后了~

　　调整之后build目录有所改变，之前重命名app.js为文件名：test/test.js,现在不重命名: test/app.js 。

　　browserify管道流不被rev支持也解决了， 引入vinyl-buffer，在browserify任务后buffer()一下，详情见最新的git

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!