Комментарии 14
Вы не могли бы выложить это в npm? Чтобы не приходилось копипастить функцию из проекта в проект.
+1
Пока я не уверен, что такая волшебная функция подойдет всем. Например, можно вспользоваться end-of-stream, а не просто слушать событие «end».
Пока это просто паттерн работы с ошибками в pipe. Когда решение дозреет до настоящего модуля – конечно опубликую
Пока это просто паттерн работы с ошибками в pipe. Когда решение дозреет до настоящего модуля – конечно опубликую
0
Так в plumber же можно передать функцию-обработчик ошибки…
+2
Что-то не понял, а зачем watch при сборке на CI сервере?
0
watch на локальной машине. Но вы же хотите в режиме watch и билда исполнять одни и те же таски?
0
Да, поэтому когда я использовал gulp, делал так:
Чего очень сильно не хватает в webpack.
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.
0
Да, это тоже решение.
Но во-первых, дополнительное условие – уже не очень здорово.
Во-вторых plumber должен включаться не в зависимости от environment, а от запускаемой задачи. Получается, нужно делать как-то так:
Команды
Но во-первых, дополнительное условие – уже не очень здорово.
Во-вторых 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-переменной0
совсем не согласен. У вас в арсенале есть еще npm-scripts.
В итоге вы можете сколько угодно менять систему сборки, разработчики вашей команды, которым они чужды могут даже об этом не знать, запуская
{
"scripts": {
"start": "gulp",
"build": "NODE_ENV=production gulp build"
}
}
В итоге вы можете сколько угодно менять систему сборки, разработчики вашей команды, которым они чужды могут даже об этом не знать, запуская
npm start
каждый раз после git pull
.0
На env обычно завязаны условия, сжимать скрипты или нет, уровень логгирования и т.д. Поэтому лучше разделять опции watch/build и minify/не-minify.
А вообще, топик совсем не об этом. А о том, что можно обойтись совсем без специального условия для watch, сделать так, чтобы и для dev-демона и для production сборки применялся один и тот же конфиг. Так ловить production-специфичные баги намного проще.
А вообще, топик совсем не об этом. А о том, что можно обойтись совсем без специального условия для watch, сделать так, чтобы и для dev-демона и для production сборки применялся один и тот же конфиг. Так ловить production-специфичные баги намного проще.
0
А что не так в webpack?
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Gulp.watch: ловим ошибки правильно