最近在写一个项目，基于gulp做一个components的工作流框架，通过这个框架去add，build，preview，test，publish，目前还在开发阶段，不过已经实现了一些基本功能，而且开发出的pipe-queue和pipe-matrix也是基于这个工作流实现的。不过这两个组件原本是为了实现我的这个框架，结果在倒腾框架的过程中诞生了这两个组件，而它们又是在框架中诞生的，真说不清是“鸡生蛋还是蛋生鸡”。
在这个过程里面，躺了很多stream pipe的坑，所以打算今天就来慢慢谈谈。事先说好，我在写的时候思维乱跳，可能会穿插一些吐槽，做好心理准备。
gulp和grunt的本质区别
我之前是在grunt上跑任务，改起来也很顺手，思维完全是清晰的，看着一个个组件在自己的工作流下面出来，心中也暗爽出一种上帝视角，这种“谜之自信”在我进入gulp开发的第三天被打碎。
gulp和grunt的本质区别在于：gulp是对文件流的一种工作流，而且完全遵守node的异步思想。而grunt嘛……并没有什么node的思想，如果一定要尊称一下，可以称之为“工作流的祖先”吧。
gulp的所有的一切都是围绕文件转，你在gulp开发里面要动的东西，永远都是文件，无论做什么事，到最后你都是为了把文件怎样怎样。比如你gulp.src是为了弄过来文件，gulp.dest是为了搞出到文件，gulp.watch是为了监视文件，对不起，“文件”不是一个人，真的是计算机里面的file。
但是，怎么搞文件呢？gulp抓住了内在核心，那就是流（stream）这个东西，虽然在node中stream有多种，但是在gulp里面，主要就是搞file stream，当然，这里面也有file buffer的戏份。但是不管怎样，gulp.src完，你一定要回到node的pipe机制，通过pipe去对文件流进行处理。处理文件流，是gulp性能上优于grunt的第一个原因。
异步并行的gulp
这个搞文件流的过程，和node一样，是异步的，也就是说当你在gulp任务中用多个pipe去处理不同的stream的时候，这几个stream的处理过程是异步的，他们会同时发生，而且一旦开始，就转到child_process里面去搞，搞完了如果你不做处理，根本不知道。这也就是为什么gulp.task的回调函数要用一种方式去通知的原因，它有三种方式通知：返回一个stream，返回一个Promise，直接调用callback。如果不做上面三选一的处理，那么gulp.task的代码执行完几乎就是一瞬间的事情，你的cli一闪而过，根本不知道后面发生了什么事情。
举个栗子更性感：
gulp.task('default',function() {
gulp.src('src/*.js').pipe(..要花1分钟处理的..).pipe(gulp.dest('dist'));
});
你以为上面这段代码会在terminal里面等一分钟以后才提示你任务完成了吗？不，绝对不会。它会告诉你default task结束啦，于是你兴冲冲跑去dist目录看，啥都没有。正确的做法是：
gulp.task('default',function() {
return gulp.src('src/*.js').pipe(..要花1分钟处理的..).pipe(gulp.dest('dist'));
});
返回的是一个stream类型，gulp会监听这个stream的情况，直到一个end的emit事件被抛出来，gulp才会提示你任务结束。
再来一个栗子让你吃饱：
gulp.task('default',function() {
gulp.src('src/*.es6').pipe(..要花1分钟转码..).pipe(gulp.dest('src'));
return gulp.src('src/*.js').pipe(..花5秒钟合并文件的..).pipe(gulp.dest('dist'));
});
gulp又提示你任务结束啦，你跑去dist目录看，尼玛什么也没有，感觉被世界欺骗了一样。上面两个stream是异步并行的，这也就是说，第一个stream和第二个stream会同时开始，所以第二个stream并没有发现src目录下的.js文件，所以草草结束了，1分钟之后src目录下才产生了.js，可是这个时候，下面个stream早都结束了，你只能再运行一遍这个任务才能实现目的。那到底要怎样才能实现我们的目的，转码完后再去执行合并文件的操作呢？这个在下文有答案。
异步是gulp获得更高性能的重要原因，然而“并行”让开发者吃尽苦头。我刚开始遇到这个情况的时候，简直就是彻夜难眠。还好，后来被我解决了，并且产生了pipe-queue这个组件。
发挥异步并行优势
异步好是好，但是你是不是感觉好像没啥用，反而给你带来了一些不方便。确实，刚开始的时候，由于“异步”我总是不能在cli里面得到自己想要的信息，由于“并行”总是导致文件无法正确处理。但是慢慢思考之后，就好像被上帝摸了一下脑袋，领悟了一些道理。
异步并行这个思想，简直就是神来之笔，让工作流效率高很多很多。
举一个栗子先：我们经常会先撰写自己的代码，然后要编译和打包，一般的流程是“js编译，然后模块的浏览器端支持，合并，混淆；样式的编译，合并，混淆”。如果按照同步串行的方式，必须按照上面的步骤一个一个去做，异步并行就不用，因为非常明显，样式的合并混淆跟js的任何一个动作都没有半毛钱关系，所以我们应该在这个任务里面把文件流分为两条线，一条处理js，一条处理css，但是必须等到这两条线都完成，才算整个任务完成。这个任务所花的时候，是比较长那条线所花的时间，而不是两条线的总和。
但是无奈，js的后面的处理步骤必须依赖前面的步骤。所以在一条线内，又必须串行。这就是坑了，暂且不说在不了解gulp相关的背景下怎么实现上面说的“完成任务的标准”，单就这个“依赖”就很麻烦。
gulp官方给出的方案是，通过task之间的依赖关系来实现，比如创建jsCompile, jsConcat, jsMinify三个任务，然后在jsConcat的依赖中加入jsCompile，在jsMinify的依赖中加入jsConcat，这样当你运行jsMinify的时候，前面两个依赖都会被执行，而且还是按照依赖的关系顺序执行。但是这种思想非常恶心，创建一个任务本来就是希望这个任务完成我想要的事情，何必拆分为多个任务呢？当然，有的时候有些小任务在不同的其他任务中都可能用到，可以单独出来，但是如果有些任务根本没有必要呢？所以，同步串行的东西，在编程世界里，也是必须要有的啊，不然node为什么也有很多sync的方法呢？
合并异步并行的stream的实现
前面提到的，A和B两条stream的pipe line并行非常棒，应该发挥这个功效，但是问题是，怎么实现判断何时这个任务才算结束，在cli中给出finished的提示呢？其实这是stream的机制，我们可以通过将A和B的两个stream注入到一个新的stream中，而这个stream里面可以去构造何时emit一个end事件。
基于这个思想，参考了别人的代码，我实现了一个pipe-concat组件，使用它可以实现这个功能。
npm install --save-dev pipe-concat
var gulp = require('gulp');
var concat = require('pipe-concat');
gulp.task('build',function() {
var stream1 = gulp.src(...).pipe(...).pipe(gulp.dest(..));
var stream2 = ...
var stream = concat(stream1,stream2);
return stream;
});
concat返回的是一个stream，所以它可以直接被return给gulp的回调函数，这样gulp在监听到这个新的stream抛出的end事件时，才会结束当前的任务。
通过上面这个方法，我们实现了并行多个异步任务，在同一个任务里面，做多件事，这样可以节省执行时间，提升我们的开发效率。
有个槽点，就是到底用concat和merge作为名称。我们知道这两个单词都有合并的意思，但是我认为concat更符合这里的场景，merge是合并，意思是会有覆盖重写的，有重复的就合并，但是concat没有，它是连接，concat真的就是把后面的往前面的尾巴上加。而我们这个地方实际上是把两条stream pipe line叠加在一起，不改变pipe line本身的任何内容，而且从空间逻辑上，他们也有先后顺序。只不过没有完全合并为一条线而已。
串行stream pipe line的实现
接下来，我们就要干一件大事，就是把并行的stream硬生生改为串行，从而实现前一个步骤完成之后，再执行后面一个步骤。这个时候，我们有了步骤的概念，有了等待被执行的概念，我就要顺势推出pipe queue的概念了。
pipe queue就是具有先后顺序的pipe line的组合。因为还没有提到pipe matrix，所以我还暂时不上图。一条pipe line其实处理了一个stream，虽然这个line中有多个pipe，但是他们的对象是连贯的，这组pipe不可以分开对待。但是pipe queue就不同了，它是line的队列，前一个line处理完毕，后面一个line才会继续。
基于这种思维，我创建了pipe-queue这个组件，使用如下：
npm install --save-dev pipe-queue
var gulp = require('gulp');
var PipeQueue = require('pipe-queue');
gulp.task('build',function() {
var stream1 = gulp.src(...).pipe(...).pipe(gulp.dest(..));
var stream2 = ...
var $queue = new PipeQueue();
$queue.when(stream1,stream2).then(function(next, concat) {
var stream1 = ...
var stream2 = ...
concat(stream1,stream2).on('end',next);
}).then(...).end(function(){
console.log('finished!');
});
return $queue.promise();
});
你在这个例子里面看到的，感觉上不是很简单，因此不说说是不行的。
首先，PipeQueue是一个类，真的是一个class类型，你可以去看源码，只不过我用babel把它转码了而已。实例化这个类后放到$queue里面，可以去调用它的when, then, end，具体的用法就不再这里说了，去我GitHub上去看，都有非常详细的说明。
为什么一定要把后面那两个stream放在函数里去，而不像when一样，直接当参数传进去？其实道理很简单，就是当参数传进去时，实际上pipe line已经开始了，stream已经在流动了，而且很快就会结束，而把他们放到then的函数里面的时候，只有去调用并运行这个函数时，里面的pipe line才会开始，这就是最终的秘诀。
另一个秘诀就是，给了一个next作为下一个then的行动信号，也就是说，如果你不在then的函数里调用next()，那么下一个then绝对不会执行，这样下一个then里面的stream也不会开始流了。
而末尾的那个promise是为了返回给gulp的，因为gulp只能通过前面说过的三种方式获得回调通知，而且callback形式在异步中是没法用的，而queue又不能返回一个stream类型，所以这里只能构造一个Promise来实现啦。
有了pipe-queue，就可以把具有依赖的两个不同的pipe line按照我们惯有的逻辑思维组织起来，比如上面的js的build过程，不用再写多个子任务，然后到依赖里面去一层套一层了。
而且，由于pipe-queue是依赖于pipe-concat实现的when方法，所以实际上如果仅仅是想并行完成pipe line，而不计较使用使用end事件的话，pipe-queue的when也可以并行完成几条line。
并行同步的stream pipe line的实现
搞定了串行的stream pipe line就剩下最后一个问题，就是我要让build js和build css那两条线同时运行，以用时更长的那条线的结束作为整个任务的结束。
思路就相对简单很多，其中两条线各自通过pipe-queue来实现，现在的问题就是，有没有一个机制可以知道哪条线跑的时间更久？这当然是可以的。这种两条线并行跑的形式，就是并行同步，也就是整体上是并行，但是每个并行的line内部是同步串行的。基于这种思想，我开发了pipe-matrix。matrix的意思是“矩阵”，我要实现的，不仅仅是几条线的并行同步执行，我希望任何一种形式都可以通过pipe-matrix去实现，所以，总得来说，pipe-matrix就是处理pipe queue的并行问题的解决方案。
上图是一个示意图，给了很多case。pipe就是一个绿色块，一个一个的管道，这些管道连接在一起就是pipe line，是stream处理的最常见形式，也是gulp里面的默认形式，即case1。而case2则是演示了当需要在几条line并行运行，且全部完成后抛出end的过程。case3则是pipe queue的演示。case4是pipe matrix的演示，pipe-matrix不仅可以让几条queue并行，而且可以在并行完之后串行至下一个matrix。
使用方法也很简单：
npm install --save-dev pipe-matrix
var gulp = require('gulp');
var PipeQueue = require('pipe-queue');
var PipeMatrix = require('pipe-matrix');
gulp.task('default',function() {
var stream1 = ...
var stream2 = ...
var $queue1 = new PipeQueue();
$queue1.when(stream1,stream2)... // 注意，这里不能使用end，即使使用了也无效
...
var $queue2 = ...
...
var $matrix = new PipeMatrix();
$matrix.when($queue1,$queue2).then(function(next) {
// ...
}).end(function(){...});
return $matrix.promise();
});
可以看到，其实pipe-matrix的用法和pipe-queue的用法非常像，只不过pipe-matrix面对的是queue，而非pipe line，这也就是说，在pipe-matrix中跟stream本身其实没多大关系了，matrix中，主要监测的，是pipe queue的完成情况，这也就是为什么我在matrix中说，如果你没有用到pipe queue，就没必要用这个组件的原因。
同步完成多个步骤的小技巧
gulp中有非常多的隐藏技巧并没有被官方文档暴露给我们，官方总是希望我们用他们希望的方式去写依赖，而实际上，我们可以用一种小技巧去避免。这就需要我们理解一下pipe，当pipe line结束的时候，stream其实还在，它被放在内存中，等待释放。而如果我们这个时候立即用另一个pipe line去操作它，那么它会被拾起来，继续投入战斗。举个栗子时间：
var stream = gulp.src(srcDir + '/js/index.js') // webpack code
.pipe(webpack({
module: {
loaders: [
{
test: /\.js$/,
loaders:['babel?{"presets":["latest"]}']
},
],
},
}))
.pipe(rename(name + '.js'))
.pipe(gulp.dest(distDir + '/js/')) // minify code
.pipe(uglify())
.pipe(rename({suffix:'.min'}))
.pipe(gulp.dest(distDir + '/js/'))
return stream;
其实上面这段代码有两个pipe line，因为在gulp.dest的时候，已经输出了文件，但是另一个pipe马上去接上，这就相当于两个分开的pipe line首尾相连，实际上就是一个pipe line。所以上面的pipe line会输出两个文件，一个是webpack打包后的原始文件，另一个是uglify压缩后并且加上.min后缀的混淆文件。
所以最后的最后，当我们再看前文js和css的任务时，其实只需要用到pipe-concat就可以了，因为js和css各自的工作流靠这里的小技巧就解决了。再通过pipe-concat合并两个stream，就可以完成我们想要的效果了。
废了这么大篇幅，从pipe-queue绕到pipe-matrix，现在又绕了回来。这就是一个不可饶恕的坑啊，也许只有在自我折腾中，才能成长吧。
有了上面这些组件，帮我们完成各类异步并串行的pipe line，基本上可以帮我们搞定所有gulp的任务了。还等什么，赶紧搞起来。
多谢老哥 很有用