GulpJS — фантастически быстрый сборщик проектов

[@xGromMx]

Эх) хотел написать о нем статью, да не успел =)

[@creage]

Что-то мне, со своим MSBuild-ом, уже как-то и неловко. Grunt, Yeoman, и теперь, вот, еще и Gulp.

[@armed]

Щупаю его уже дня три, все очень, сказал бы, Nodejs-style. Прощай grunt.

[@aen]

Теперь будет еще одна тема для холиваров: Gulp vs Grunt

[@IonDen]

Думаю, хороший конкурент заставит Grunt напрячь булки и запилить оптимизацию.

[@VasilioRuzanni]

С одной стороны в Grunt хватает всего, но с другой — Gulp — свежий глоток воздуха и более приятный API. В сети идут постоянные холивары по теме, не пойму из за чего — хорошо, когда есть конкуренция, мы все от этого выигрываем. Отправлять Grunt на свалку, разумеется, рано — плагинов для него куда больше, но Gulp выглядит вполне достойно.

[@GruZZ]

npmjs.org/package/gulp-grunt — кстати, вот этот плагин меня прям радует.

[@VasilioRuzanni]

О, спасибо, круто!

[@GruZZ]

blog.ponyfoo.com/2014/01/09/gulp-grunt-whatever — без этой ссылки пост был бы неполным.

[@exdeniz]

Да, наверно. Там много холиварного, особенно про 2000 плагинов чуть-ли не через строчку. В плагинах Grunt можно копаться, копаться и еще раз копаться. В конце концов отмести 1800, как бесполезные для тебя и двигаться дальше.
На самом деле надо просто перестать сравнивать их, они разные и начать использовать хоть что-то из них.

[@Fesor]

с виду принципиальных отличий от grunt нету… нужно пробовать… с ходу все что нужно из плагинов есть либо легко прикручивается…

[@Dmitry_f]

Не понимаю, где может быть так важна скорость сборки проектов, чтобы переписывать grunt? Это же одноразовая операция.

[@Fesor]

Почему одноразовая? Я к примеру использую ватчеры для ребилда приложения, и мне хочется что бы это все выполнялось так быстро, насколько это возможно, что бы пока я переключаюсь из IDE в браузер, сборка уже отработала и livereload хотя бы начал перезагружать страницу.

[@Dmitry_f]

Тогда ситуация противоречивая. Если у вас небольшой проект — то сборка на гранте не должна создавать ощутимых задержек при сборке.
Если проект большой — то переход на gulp займет больше времени, чем gulp сможет сэкономить за все время его использования в качестве моментального сборщика.

[@Fesor]

Несомненным плюсом gulp-а является работа через текстовые потоки. Во первых потому что это эдакий unix true way, и во вторых, нет необходимости в промежуточных файлах (эту проблему я в grunt сходу решить не смог, и иногда приходится выдумывать «куда же положить файлик обработанный ngmin перед тем как скормить его google-closure...). Мелочь а приятно.

По поводу масштабов проекта: я обычно разделяю проект на отдельные модули и собираю только измененную часть. Целиком проект собирается только раз, перед стартом ватчеров.

[@Dmitry_f]

А зачем промежуточный файл? Почему финальный файл не обрабатывать closure-compiler и пр?

[@Fesor]

Ну промежуточный файл все равно же создается… Либо тогда отказаться вовсе от grunt (все же все эти штуки доступны в виде простых консольных команд) и настроить сборку через ant с использованием тех же текстовых потоков.

[@exdeniz]

Создает, если есть последовательная обработка файлов. Например Stylus > autoprefixer и т.п.

[@zag2art]

А как в нем source maps? Есть ли плагин для browserify?

[@exdeniz]

Для browserify плагин есть, а что имеется ввиду под «в нем source map есть»?

[@Fesor]

source map должен быть у минификаторов, а никак у сборщика.

[@MuLLtiQ]

Browserify поддерживает source maps для маппинга собранного через browserify файла в исходные js-файлы.

[@Fesor]

и все же причем тут grunt/gulp? пусть себе Browserify поддерживает source maps, он же доступен как модуль для npm, так что никаких ограничений gulp наложить не может.

[@MuLLtiQ]

Grunt и Gulp — task-менеджеры (или task-runner-ы). Под «сборщиком» я имел ввиду Browserify, поэтому неправильно понял вашу мысль в комментарии. Разумеется Gulp никаких ограничений наложить не может — вы в любом случае можете использовать Browserify и другие библиотеки, даже если у вас нет специального плагина для этого.

[@gagoman]

Кто-то сравнивал с brunch.io?
cast paulmillr

[@exdeniz]

Ну это же это более узкая утилита, что бы с ней сравнивать.

[@exdeniz]

Для инкрементальной есть плагин — github.com/floatdrop/gulp-watch который решает это.

Да соединения файлов можно использовать github.com/wearefractal/gulp-concat который тоже решит это.

А так конечно, brunch.io, mimosa.io это инструменты простые, но имеющие меньшую гибкость.

[@exdeniz]

То есть при изменении одного файла, у них запустится пайплайн компиляции без поддержки кэшей и тд — медленно если файлов много.

я уже писал про проект на ~1000 файлов, реально сборка их и обработка Myth составляет 0.5 секунды.

[@exdeniz]

Я просто отказался от сасс в пользу stylus и ничего не могу сказать по этому поводу. Но бродят твиты twitter.com/markgdyr/status/422485258471505920, где сборку с 24 секунд сократили до 0.9

[@delch]

Не нашел описания как использовать coffeescript в том же gulpfile… Он так может?

[@exdeniz]

А что значит использовать coffeescript? В плане собирать, то да. Для gulpfile.js не знаю…

[@delch]

В плане gulpfile.coffee использовать вместо gulpfile.js и писать на coffeescript сам gulpfile. Я так понял, что это сейчас не возможно, это минус(
Кстати, я так понимаю стандартный плагин gulp-stylus не может мне собирать blocks.styl в style.css?

[@exdeniz]

Не понял зачем это?

gulp.task('stylusIE', function () {
  gulp.src('static/b/**/*.ie.styl')
    .pipe(plumber())
    .pipe(stylus())
    .pipe(concat("screen.ie.css"))
    .pipe(myth())
    .pipe(gulp.dest('static/css/'))
    .pipe(livereload(server));
});

Вот такая конструкция собирает все файлы для ie из всех папок
После .pipe(concat(«screen.ie.css»)) делаем один файл и дальше уже обрабатываем.

gulp.task('stylus', function () {
  gulp.src('static/b/blocks.styl')
    .pipe(plumber())
    .pipe(stylus())
    .pipe(myth())
    .pipe(rename("screen.prefix.css"))
    .pipe(gulp.dest('static/css/'))
    .pipe(livereload(server));
});

А такая по import из blocks.styl

[@delch]

Ну я может что то делаю не так.
К примеру:
b/header/header.styl
b/content/content.styl
b/footer/footer.styl

Есть global.styl в котором все импорты из b/. Я хочу, чтобы у меня в build/css лежал один styles.css.

[@exdeniz]

Ну я же привел примеры.
gulp.src('static/b/blocks.styl') для сборки из import
gulp.src('static/b/**/*.styl') для сборки всех файлов без import

[@exdeniz]

gulp.task('stylus', function () {
  gulp.src('./b/global.styl')
    .pipe(plumber())
    .pipe(stylus())
    .pipe(rename("style.css"))
    .pipe(gulp.dest('./build/css'))
    .pipe(livereload(server));
});

Конкретно под твой пример, не забудь только проинициализировать модули.

[@exdeniz]

А и да что бы использовать coffee для файла конфигурации запускаем

gulp watch --require coffee-script

или создаем
gulpfile.js

в котором

require('coffee-script');
require('./gulpfile.coffee');

[@delch]

Спасибо!

[@oshibka404]

Думаю, автору будет приятно узнать, что я регулярно использую эту статью как шпаргалку, и рекомендую её друзьям.
Спасибо за материал.

[@exdeniz]

Пожалуйста. Надо на самом деле обновить будет.

[@xGromMx]

Нашел как-то такой генератор quenchjs.com

[@loststylus]

Почему он так через задницу устанавливается?

> npm install gulp gulp-jade gulp-stylus gulp-livereload gulp-myth gulp-csso gulp-imagemin gulp-uglify gulp-concat connect --save-dev

Почему не просто npm install gulp? Кто-нибудь может объяснить? И почему на оффсайте этого не написано? Как я должен был догадаться?

[@Fesor]

потому что помимо gulp в этом случае ставится еще пачка плагинов. Грубо говоря так будет понятнее:

npm install --save-dev \
    gulp \
    gulp-jade \
    gulp-stylus \
    gulp-livereload \
    gulp-myth \
    gulp-csso \
    gulp-imagemin \
    gulp-uglify \
    gulp-concat \
    connect

Просто так проще, нежели писать пачку команд вида npm install --save-dev gulp && npm install --save-dev gulp-concat и т.д.

К слову в списке плагинов нет sourcemaps, без него сборка не полноценна.

[@exdeniz]

На момент написания статьи sourcemaps не было еще, он появился позже.

[@Fesor]

а ну да, не посмотрел на дату.