Comments 48
Что-то мне, со своим MSBuild-ом, уже как-то и неловко. Grunt, Yeoman, и теперь, вот, еще и Gulp.
Щупаю его уже дня три, все очень, сказал бы, Nodejs-style. Прощай grunt.
Думаю, хороший конкурент заставит Grunt напрячь булки и запилить оптимизацию.
С одной стороны в Grunt хватает всего, но с другой — Gulp — свежий глоток воздуха и более приятный API. В сети идут постоянные холивары по теме, не пойму из за чего — хорошо, когда есть конкуренция, мы все от этого выигрываем. Отправлять Grunt на свалку, разумеется, рано — плагинов для него куда больше, но Gulp выглядит вполне достойно.
Да, наверно. Там много холиварного, особенно про 2000 плагинов чуть-ли не через строчку. В плагинах Grunt можно копаться, копаться и еще раз копаться. В конце концов отмести 1800, как бесполезные для тебя и двигаться дальше.
На самом деле надо просто перестать сравнивать их, они разные и начать использовать хоть что-то из них.
с виду принципиальных отличий от grunt нету… нужно пробовать… с ходу все что нужно из плагинов есть либо легко прикручивается…
Не понимаю, где может быть так важна скорость сборки проектов, чтобы переписывать grunt? Это же одноразовая операция.
Почему одноразовая? Я к примеру использую ватчеры для ребилда приложения, и мне хочется что бы это все выполнялось так быстро, насколько это возможно, что бы пока я переключаюсь из IDE в браузер, сборка уже отработала и livereload хотя бы начал перезагружать страницу.
Тогда ситуация противоречивая. Если у вас небольшой проект — то сборка на гранте не должна создавать ощутимых задержек при сборке.
Если проект большой — то переход на gulp займет больше времени, чем gulp сможет сэкономить за все время его использования в качестве моментального сборщика.
Несомненным плюсом gulp-а является работа через текстовые потоки. Во первых потому что это эдакий unix true way, и во вторых, нет необходимости в промежуточных файлах (эту проблему я в grunt сходу решить не смог, и иногда приходится выдумывать «куда же положить файлик обработанный ngmin перед тем как скормить его google-closure...). Мелочь а приятно.

По поводу масштабов проекта: я обычно разделяю проект на отдельные модули и собираю только измененную часть. Целиком проект собирается только раз, перед стартом ватчеров.
А зачем промежуточный файл? Почему финальный файл не обрабатывать closure-compiler и пр?
Ну промежуточный файл все равно же создается… Либо тогда отказаться вовсе от grunt (все же все эти штуки доступны в виде простых консольных команд) и настроить сборку через ant с использованием тех же текстовых потоков.
Создает, если есть последовательная обработка файлов. Например Stylus > autoprefixer и т.п.
Для browserify плагин есть, а что имеется ввиду под «в нем source map есть»?
Browserify поддерживает source maps для маппинга собранного через browserify файла в исходные js-файлы.
и все же причем тут grunt/gulp? пусть себе Browserify поддерживает source maps, он же доступен как модуль для npm, так что никаких ограничений gulp наложить не может.
Grunt и Gulp — task-менеджеры (или task-runner-ы). Под «сборщиком» я имел ввиду Browserify, поэтому неправильно понял вашу мысль в комментарии. Разумеется Gulp никаких ограничений наложить не может — вы в любом случае можете использовать Browserify и другие библиотеки, даже если у вас нет специального плагина для этого.
Да, бранч решает чисто фронтэндовские проблемы. Галп подойдет много для чего.
Та же тема, что и грант, только значительно чище и проще. Однозначно лучше гранта.

Но проблемы, которые решаются бранчем оно не решает.

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

Для сложных проектов все еще нужно много настраивать. Например, «взять все файлы с bower, отсортировать и сгруппировать по зависимостям, добавить в очередь компиляции перед остальными файлами проекта, все свалить в один файл» — такое было бы не очень просто.

Или даже банально — есть файлы coffeescript и jade. Как их скомпилять в один файл? Вижу как сделать два таска которые будут вотчить a) *.coffee b) *.jade и компилять в разные файлы, но не в один. Разве что через какую-то промежуточную функцию / таск.
То есть при изменении одного файла, у них запустится пайплайн компиляции без поддержки кэшей и тд — медленно если файлов много.


я уже писал про проект на ~1000 файлов, реально сборка их и обработка Myth составляет 0.5 секунды.
Миф используют, думаю, 0.01-0.1% людей от всех кто юзает альтернативные CSS-препроцессоры. Так что он не особо релевантен.

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

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
Ну я может что то делаю не так.
К примеру:
b/header/header.styl
b/content/content.styl
b/footer/footer.styl

Есть global.styl в котором все импорты из b/. Я хочу, чтобы у меня в build/css лежал один styles.css.
Ну я же привел примеры.
gulp.src('static/b/blocks.styl') для сборки из import
gulp.src('static/b/**/*.styl') для сборки всех файлов без import
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));
});


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

gulp watch --require coffee-script

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

в котором
require('coffee-script');
require('./gulpfile.coffee');
Думаю, автору будет приятно узнать, что я регулярно использую эту статью как шпаргалку, и рекомендую её друзьям.
Спасибо за материал.
Почему он так через задницу устанавливается?

> 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? Кто-нибудь может объяснить? И почему на оффсайте этого не написано? Как я должен был догадаться?
потому что помимо 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, без него сборка не полноценна.
На момент написания статьи sourcemaps не было еще, он появился позже.
Only those users with full accounts are able to leave comments. Log in, please.