pump = require('pump')
https://github.com/terinjokes/gulp-uglify/blob/master/docs/why-use-pump/README.md#why-use-pumphtml
當使用來自Node.js的管道時,錯誤不會經過管道流向前傳播,若是目標流關閉,源流也不會關閉。pump模塊將這些問題規範化,並在回調中傳遞錯誤。node
pump可使咱們更容易找到代碼出錯位置。git
A common pattern in gulp files is to simply return a Node.js stream, and expect the gulp tool to handle errors.github
gulp文件中的一個常見模式是簡單地返回一個Node.js流,並期待gulp工具能處理錯誤gulp
// example of a common gulpfile var gulp = require('gulp'); var uglify = require('gulp-uglify'); gulp.task('compress', function () { // returns a Node.js stream, but no handling of error messages return gulp.src('lib/*.js') .pipe(uglify()) .pipe(gulp.dest('dist')); });
There’s an error in one of the JavaScript files, but that error message is the opposite of helpful. You want to know what file and line contains the error. So what is this mess?api
這裏有一個錯誤在某個JavaScript文件中,可是這些錯誤信息並無起到什麼做用。咱們真正想要知道的是哪一個文件的哪一行出現了這些錯誤。app
When there’s an error in a stream, the Node.js stream fire the 'error' event, but if there’s no handler for this event, it instead goes to the defined uncaught exception handler. The default behavior of the uncaught exception handler is documented:ide
當在流中出現了錯誤時,將會觸發'error'事件,可是若是這裏的事件沒有handler的話,它將會定義一個沒有捕捉的異常handler,以下文檔說明:函數
By default, Node.js handles such exceptions by printing the stack trace to stderr and exiting.默認狀況下,Node.js經過將堆棧跟蹤打印到stderr和退出來處理這些異常工具
Since allowing the errors to make it to the uncaught exception handler isn’t useful, we should handle the exceptions properly. Let’s give that a quick shot.
即然若是不處理異常將默認爲uncaught exception handler(這是沒有用的),那麼咱們就應該恰當地對異常進行處理
var gulp = require('gulp'); var uglify = require('gulp-uglify'); gulp.task('compress', function () { return gulp.src('lib/*.js') .pipe(uglify()) .pipe(gulp.dest('dist')) .on('error', function(err) { //添加一個異常處理 console.error('Error in compress task', err.toString()); }); });
Unfortunately, Node.js stream’s pipe
function doesn’t forward errors through the chain, so this error handler only handles the errors given by gulp.dest
. Instead we need to handle errors for each stream.
可是這個異常處理是不會經過鏈來傳遞錯誤的,因此它只會處理來自 gulp.dest
的錯誤。那麼若是咱們要處理每個流的錯誤的話,就要像下面同樣,每一個流都進行錯誤處理
var gulp = require('gulp'); var uglify = require('gulp-uglify'); gulp.task('compress', function () { function createErrorHandler(name) { return function (err) { console.error('Error from ' + name + ' in compress task', err.toString()); }; } return gulp.src('lib/*.js') .on('error', createErrorHandler('gulp.src')) .pipe(uglify()) .on('error', createErrorHandler('uglify')) .pipe(gulp.dest('dist')) .on('error', createErrorHandler('gulp.dest')); });
This is a lot of complexity to add in each of your gulp tasks, and it’s easy to forget to do it. In addition, it’s still not perfect, as it doesn’t properly signal to gulp’s task system that the task has failed. We can fix this, and we can handle the other pesky issues with error propogations with streams, but it’s even more work!
這樣就會變得很複雜,並且你也很容易就忘記這麼作。因此咱們須要使用pump
The pump
module is a cheat code of sorts. It’s a wrapper around the pipe
functionality that handles these cases for you, so you can stop hacking on your gulpfiles, and get back to hacking new features into your app.
它是用來處理上面這些狀況的pipe的包裝器,這樣您就能夠中止對您的gulpfile文件進行黑客攻擊,並從新對您的應用程序進行黑客攻擊
var gulp = require('gulp'); var uglify = require('gulp-uglify'); var pump = require('pump'); gulp.task('compress', function (cb) { pump([ gulp.src('lib/*.js'), uglify(), gulp.dest('dist') ], cb //回調函數 ); });
The gulp task system provides a gulp task with a callback, which can signal successful task completion (being called with no arguments), or a task failure (being called with an Error argument). Fortunately, this is the exact same format pump
uses!
Now it’s very clear what plugin the error was from, what the error actually was, and from what file and line number.
這樣咱們就可以看見是什麼觸發了error,在哪一個文件的哪一行
這只是一個簡單的瞭解,若是想要更深刻的學習請自學https://github.com/pump-io/pump.io
以後若是看了這部分再寫出來