Comments 14
Вы не могли бы выложить это в npm? Чтобы не приходилось копипастить функцию из проекта в проект.
Пока я не уверен, что такая волшебная функция подойдет всем. Например, можно вспользоваться end-of-stream, а не просто слушать событие «end».

Пока это просто паттерн работы с ошибками в pipe. Когда решение дозреет до настоящего модуля – конечно опубликую
И что нужно написать в обработчике ошибки, чтобы gulp узнал, что task провалился?
watch на локальной машине. Но вы же хотите в режиме watch и билда исполнять одни и те же таски?
Да, поэтому когда я использовал gulp, делал так:
var gulp = require('gulp');
var _if = require('gulp-if');

var env = process.env.NODE_ENV || 'development';
var production = env === 'production';

gulp.task('less', function () {
  gulp.src('less/*.less')
      .pipe(_if(!production, plumber()))
      .pipe(less())
});

Чего очень сильно не хватает в webpack.
Да, это тоже решение.

Но во-первых, дополнительное условие – уже не очень здорово.
Во-вторых plumber должен включаться не в зависимости от environment, а от запускаемой задачи. Получается, нужно делать как-то так:

var usePlumber = false;
gulp.task('dev', function() {
     usePlumber = true;
     gulp.start()
});

gulp.task('less', function () {
  gulp.src('less/*.less')
      .pipe(_if(usePlumber, plumber()))
      .pipe(less())
});


Команды gulp dev и gulp build (подозреваю, что вы собираете не только стили) задокументировать и объяснить другим участникам команды проще, чем в комбинации с environment-переменной
совсем не согласен. У вас в арсенале есть еще npm-scripts.
{
  "scripts": {
    "start": "gulp",
    "build": "NODE_ENV=production gulp build"
  }
}

В итоге вы можете сколько угодно менять систему сборки, разработчики вашей команды, которым они чужды могут даже об этом не знать, запуская npm start каждый раз после git pull.
На env обычно завязаны условия, сжимать скрипты или нет, уровень логгирования и т.д. Поэтому лучше разделять опции watch/build и minify/не-minify.

А вообще, топик совсем не об этом. А о том, что можно обойтись совсем без специального условия для watch, сделать так, чтобы и для dev-демона и для production сборки применялся один и тот же конфиг. Так ловить production-специфичные баги намного проще.
На мой взгляд вашу проблему лучше решать с помощью готовых инструментов, обернув plumber, или аналог, в if. А использовать NODE_ENV, или ENABLE_PLUMBER — это уже вам решать.
Тем что правила описываются внутри объекта, который разработчик строит как угодно, на свое усмотрение.
Only those users with full accounts are able to leave comments. Log in, please.