Pull to refresh

Comments 14

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

Пока это просто паттерн работы с ошибками в pipe. Когда решение дозреет до настоящего модуля – конечно опубликую
Так в plumber же можно передать функцию-обработчик ошибки…
И что нужно написать в обработчике ошибки, чтобы gulp узнал, что task провалился?
Прошу прощения, неверно понял суть вопроса.
Что-то не понял, а зачем watch при сборке на CI сервере?
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 — это уже вам решать.
Тем что правила описываются внутри объекта, который разработчик строит как угодно, на свое усмотрение.
Sign up to leave a comment.

Articles