Skip to content

Instantly share code, notes, and snippets.

Last active January 18, 2021 03:54
Show Gist options
  • Star 66 You must be signed in to star a gist
  • Fork 3 You must be signed in to fork a gist
  • Save floatdrop/8269868 to your computer and use it in GitHub Desktop.
Save floatdrop/8269868 to your computer and use it in GitHub Desktop.
Error management in gulp

#Error management in gulp

Sucking at something is the first step to becoming sorta good at something

No one can assure you, that plugins will run smooth in any circumstances (except for tests - they could), so neither should you convince anyone, that your plugin will never break. Only thing, that you could possibly do (if something gone wrong) - is gracefully inform your plugin user, that something went wrong and die.

We are will use this plugin from beginning to demonstrate error management. Suppose you have a task in gulpfile.js that contains this code (we modified it a little bit to be closer to real-usage):

var coffee = require('gulp-coffee');

  .pipe(gulpPrefixer('// Copyright 2014 (C) Aswesome company'))

What could possibly go wrong? Well gulpPrefixer could emit errors event, as any of Stream gulp-plugins, for example gulp-sass. If you don't do anything with it inside task, Node will throw errors and whole task will be stopped.

You can easily avoid it by catch them and show by appending .on('error', gutil.log) handlers:

  .pipe(gulpPrefixer('// Copyright 2014 (C) Aswesome company'))
  .on('error', gutil.log)
  .on('error', gutil.log)

But this will not solve "stopping" problem of the task. By design, Node stream will stop accepting incoming data, if error event was raised. You can see it in stream.js:103 - cleanup function will deattach ondata handler from source (which in our case is gulp.src) and coffee plugin will stop receiving files although, the rest of the files can be compiled.

For now, we have no other solution besides patching pipe function behaviour. So the gulp-plumber may fix this problem:

  .pipe(gulpPrefixer('// Copyright 2014 (C) Aswesome company'))

Note: This will work only if Stream class used in gulp-plugin will not panic on error event and stop being writable/readable.

Copy link

Do we really need gulp-plumber in 2016? It seems that the watch do not stops when the error is occurred. Tried several times and everything is working fine.

gulp.task('styles', function() {   
 return gulp.src('public/sass/*.scss')
   .pipe(sass(SassOptions).on('error', sass.logError))

Copy link

normbr commented Sep 7, 2016

I think FieryCod has a good question...any plumber still needed?

Copy link

Hi guys,
Did someone here manage to have gulp work nicely with stylus ? I have set a small watch task with a pipe through stylus, autoprefixer and others, and it crashes altogether if stylus encounters a problem on compiling (like a bad indent).

Copy link


I assume you mean this:

gulp.plumbedSrc = (...args) => gulp.src(...args).pipe(plumber());

Copy link

absolux commented Mar 14, 2017

😆 😃

gulp.plumbed = () => gulp.src(...arguments).pipe(plumber())

Copy link



gulp.plmbd = () => gulp.src(...args).pipe(plumber())

Copy link

ankit-chheda commented May 19, 2017

@FieryCod This is mid of 2017 and yes plumber is a go-away-error kind of tool. Many plugins, particularly gulp-sass throw@import error because file is not ready or unreadable. Whenever sass compiler complies SASS files, dont know how, but it takes more time in pipe and next command is already ready to read the file as soon as file is made but not closed. I know this may sound lame, but something like this happens when you try to compile sass, concatenate other css and minify them in a single function. In this case, plumber and wait() is a work-around to let things going.

Copy link

plumber can solve the pro,that's just what i need

Copy link

Joelsz commented Jun 15, 2018

Thanks @sassy-ankit that cleared my way to use plumber for gulp-sass

Copy link

I wish you explain in more detail the circumstances under which

But this will not solve "stopping" problem of the task. By design, Node stream will stop accepting incoming data, if error event was raised.

is a problem. Unhandled exceptions are certainly a problem - but isn't "stopping on error" the a reasonable default behavior?

Copy link

DLiblik commented Jul 26, 2020

@craigphicks old comment, but in case anyone ends up here... an error in one file in the task doesn't always mean the desire is to have the whole process grind to a halt - depends on the task. This whole conversation covers creating the option to choose.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment