Pull to refresh

Comments 48

Эх) хотел написать о нем статью, да не успел =)
Что-то мне, со своим MSBuild-ом, уже как-то и неловко. Grunt, Yeoman, и теперь, вот, еще и Gulp.
Щупаю его уже дня три, все очень, сказал бы, Nodejs-style. Прощай grunt.
Теперь будет еще одна тема для холиваров: Gulp vs 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 и т.п.
А как в нем source maps? Есть ли плагин для browserify?
Для browserify плагин есть, а что имеется ввиду под «в нем source map есть»?
source map должен быть у минификаторов, а никак у сборщика.
Browserify поддерживает source maps для маппинга собранного через browserify файла в исходные js-файлы.
и все же причем тут grunt/gulp? пусть себе Browserify поддерживает source maps, он же доступен как модуль для npm, так что никаких ограничений gulp наложить не может.
Grunt и Gulp — task-менеджеры (или task-runner-ы). Под «сборщиком» я имел ввиду Browserify, поэтому неправильно понял вашу мысль в комментарии. Разумеется Gulp никаких ограничений наложить не может — вы в любом случае можете использовать Browserify и другие библиотеки, даже если у вас нет специального плагина для этого.
Ну это же это более узкая утилита, что бы с ней сравнивать.
UFO just landed and posted this here
UFO just landed and posted this here
Для инкрементальной есть плагин — github.com/floatdrop/gulp-watch который решает это.

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

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


я уже писал про проект на ~1000 файлов, реально сборка их и обработка Myth составляет 0.5 секунды.
UFO just landed and posted this here
Я просто отказался от сасс в пользу stylus и ничего не могу сказать по этому поводу. Но бродят твиты twitter.com/markgdyr/status/422485258471505920, где сборку с 24 секунд сократили до 0.9
Не нашел описания как использовать 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 не было еще, он появился позже.
а ну да, не посмотрел на дату.
Sign up to leave a comment.

Articles