Продвинутый Gulp и Browserify: интересные трюки

[Jabher]

Да, постараюсь. Как только обновлю проект на новую версию с рекомендациями (оно пока убрано в дев-ветку по ряду причин), сразу же опубликую.

Только это не nodejs приложение, все на клиентсайде :) В Web Workers. Пересчет сети на ~600 тренировочных данных и выдача около 100 значений занимает около 0.15 секунды, что вызывает просадку по перформансу. С воркерами — все нормально работает.
На всякий случай: я использовал готовую библиотеку, но там были достаточно интересные ньюансы, связанные именно с обучением.

Постараюсь в течении недели это все сделать.

[novoselov]

дежавю

[Jabher]

Я уже писал в шапке — прилетело НЛО, поэтому я почистил ссылки на проект и повторно опубликовал. Там было около 200 просмотров всего и НЛО прилетело через 15 минут после публикации, так что могли видеть, но вряд ли.

[novoselov]

Я не просто видел, но и полностью прочел :)

[AMar4enko]

Обработку ошибок без подвисания стрима можно сделать через gulp-plumber. Его офигенный плюс, что он работает на уровне pipe, следовательно нет необходимости в каждом плагине делать .on

gulp.src('*.js')
  .pipe(gulp_plumber())
  .pipe(something_what_can_throw_error()) 
  .pipe(gulp.dest('build'));

Насчет замены sass на stylus ради ускорения компиляции — gulp-sass использует для компиляции node-реализацию процессора, libsass. Отрабатывает практически моментально даже на здоровенных файлах.
К нему можно добавить compass с помощью bower-пакета compass-mixins, специально созданного для замены ruby-compass в libsass.
Жаль, что не была затронута тема инкрементальных билдов.

[Jabher]

Про plumber — спасибо, гляну, я в свое время видел его, но понял, что он просто решает какую-то специфическую проблему под windows, поэтому его все пихают «на всякий случай».

libsass быстрый, но поддерживает, что пародоксально, не sass, но только scss-синтаксис (во всяком случае, так было полгода назад, насколько я помню). А у нас в той команде почему-то так завелось, что форматирование не отступами доставляло всегда кучу проблем при мердже — потому и был переход с хтмл на jade, та же самая ерунда была. Форматирование отступами позволило сливать ветки гита с куда меньшей кучей геммороя.

Про инкрементальные билды — в моем случае все решалось установкой кэша для browserify в последнее время — у меня в том числе стили подключаются через JS по ряду причин.

[RustamS]

Используете ли gulp-watch? С ним часто происходят ошибки при создании/удалении каталогов, и gulp-plumber не подавляет их. Нет ли решения такой проблемы?
github.com/gulpjs/gulp/issues/660 github.com/floatdrop/gulp-watch/issues/83

[AMar4enko]

Да, gulp-watch использую очень активно, но ни разу не встречался с вышеупомянутыми ошибками. Посмотрел issues — может быть это потому, что у меня OS X.

[Aetet]

Уже решено: github.com/floatdrop/gulp-batch

[akzhan]

эм, жесть кое-где

Перевести весь coffeescript на JS для ускорения компиляции — благо, это были в основном старые виджеты;

я хоть и использую сейчас grunt, но почему, почему не использовать хотя бы gulp-changed?

инкрементальный pipeline гораздо эффективнее. и не приходится отказываться от нормального Coffee или Type.

[Jabher]

Там действительно был старый код, который уже не модифицировался — разные либы и так далее :) С инкрементальным билдом были определенные проблемы из-за особенностей сборки, там довольно были специфичные детали типа shared-кода и кода, генерируемого и хранящегося на сервере в памяти, сейчас я вижу это решаемым, тогда — это вызывало неллюзорные проблемы. И если правильно помню, один замороченный не очень популярный плагин тек, так что сборку приходилось перезапускать регулярно.
Плюс — как выше заметили уже, тогда в gulp-watch была проблема с удалением (или переименованием) новых папок, из-за этого оно стабильно вылетало. Компонетный подход с кучей папок был, которые периодически переименовывались.
В любом случае, собрать старые либы, которые уже не изменялись, в том числе для первоначальной «раскрутки» сборщика — лишним не было.

[princed]

Потому что нельзя было просто взять и настроить в browserify сборку Stylus-стилей, которые бы еще и высасывали base64-картинки, и проходили бы через автопрефиксер и минификацию.

Ах, вы ещё не слышали про webpack?

[Jabher]

Хм. Посмотрел — да, действительно, есть какой-то аналог пайплайна.
Из явных минусов — отсутствие подсветки путей в IDE (я в webStorm обычно набираю имя файла, жамкаю cmd-enter и там есть пункт «создать файл по заданному пути и сразу открыть его»).
Очень вряд ли — возможность создавать свой синтаксис для инклуда одних типов файлов в другие. У меня лично последние два проекта — модули для хрома, там очень много компонентов, всунутых через shadow DOM, там нужно объявлять стили внутри шаблона, соответственно их нужно как-то подключать. Вариант, когда какой-то символ просто превращается в ..." + require($1) + "… — куда удобнее.
Сомневаюсь (просто не понял, честно говоря), как там подсасывать base64, так что 50/50%, может и есть оно.

В любом случае, это выбор каждого, но я пока что продолжу доверять gulp и browserify, которые мейнтейнятся двумя жирными такими сообществами, чем вебпаку, у которого автор явно пишет «чуваки, я это делаю в свободное время». Может, когда-нибудь потом, тем более что мои задачи вполне решаемы именно так.