Опыт работы с GruntJS

[@Fesor]

После года работы с грантом я начал задумываться над написанием своего велосипеда. С одной стороны огромное количество готовых штук это круто, с другой, если требуется нечто сложнее того, что тебе9 дают, уже приходится переписывать плагины… сейчас вместо огромных конфигов я стараюсь писать плагины сборщики под конкретную структуру проекта. Это удобнее и дает больше возможностей.

[@asheee]

А можете показать пример? Очень интересно посмотреть

[@Fesor]

Вы можете посмотреть подобный подход при сборке ангулара.

[@rma4ok]

Пользуйтесь уже тогда моим grunt-bg-shell. Он позволяет запускать shell комманды параллельно в бэкграунде

[@asheee]

Да, я уже присматриваюсь к нему.

[@jetman]

В нашем проекте относительно много файлов. Примерно тысячи 2. Так вот, если покрыть livereload’ом все (с разными тасками, конечно), то nodejs начинает падать.

Пробовали увеличить лимит открытых файлов? На Mac по умолчанию 256, на Linux — 1024, на Win — не знаю.

[@Fesor]

Я обычно использую ивенты ватчера что бы производить ребилд/релоад на всего проекта, а только его части. Это заметно ускоряет сборку.

[@asheee]

Ну да. Мы делаем так же. Отдельно смотрим за JS, отдельно за шаблонами, отдельно за Less. Пытались еще и за остальными файлами смотреть, но не получилось.

[@Fesor]

У меня несколько другая структура проекта. Приложение разбито на модули, при изменении отдельных частей приложения ребилдится только часть оных, по изменению картинки/шаблона копируется только один файл или обрабатывается только один файл… Только less ребилдится целиком.
А уже для продакшена производится финальные оптимизации, минификация, конкатенация нужных модулей (если они точно должны работать вместе), загрузка шаблонов в JS…

[@asheee]

Согласен, так намного лучше.

Мы работали не с grunt-contrib-watch, а с grunt-contrib-livereload и grunt-regarde. А он не умеет отслеживать в каких файлах произошли изменения. Месяцев 5 назад watch еще не умел делать livereload.

[@Fesor]

Это да.

[@ComodoHacker]

делали мы интерактивную книгу одного популярного российского писателя. Книжка написана на JS

Доставляет. :)

[@a_b]

— У меня есть две переменных, как мне их сложить?
— Я поставил плагин “jquery.math”, очень удобно!

сильно зависит от типов переменных и задачи :)

[@Delka]

«Пример Gruntfile» — это ваш рабочий? Там нет 200 строк кода :)
Хочется побольше подробностей про Gruntfile.js, плагины которые вы используете, почему выбрали именно их, а от чего отказались, про грабли и наоборот про классные штуки, на которые надо обратить внимание.

[@GruZZ]

Мне начать разбираться с GruntJS помогли 3 ссылки:

• Пост про Grunt 0.4 в блоге Артёма sapegin Сапегина.
• Gruntfile.js из Фоторамы Артёма artpolikarpov Поликарпова.
• Поиск плагинов, выбор интересных и нужных, сравнение их «по звёздочкам» на github'е.

А вот список плагинов, которые я использую для вёрстки:

• grunt-enb
  Плагин для запуска ENB. Он только для тех, у кого БЭМ головного мозга и кто не любит bem-tools.
• grunt-favicons
  Генерирует кучу favicons из PNG. Тему раскрывает не полностью, но все равно полезный.
• grunt-imgo
  Плагин для оптимизации картинок. Сначала требуется установить сам imgo, что само по себе является не самой тривиальной задачей. Но кому надо справится, спасибо Александру banzalik Бойченко за утилиту.
  
• grunt-contrib-copy, grunt-rename, grunt-text-replace, grunt-contrib-clean
  Плагины для манипуляций с файлами, тут ничего не выбиралось, брался первый попавшийся и работающий.
• grunt-prettify
  Плагин для причёсывания HTML. Просто для красоты, чтобы не отдавать разработчикам сжатый в одну строчку HTML.
• grunt-cssbeautifier
  Плагин для причесывания CSS. Так же для красоты, но может применяться и для исходников. Осторожно, может сломать отступы в каком-нибудь stylus.
• grunt-csso
  Структурная оптимизация и минификация CSS. Я использую только стуктурную оптимизацию из-за специфики своей работы.
• grunt-csscomb
  Плагин для изначального CSScomb Славы miripiruni Олиянчука. У меня на Ubuntu работает не очень стабильно, куча php-процессов не завершаются вовремя, выжирают процессор и сильно глушат производительность системы.
  Есть уже JS-версия от Михаила mishanga Трошева, но grunt плагина под неё я не встречал.
• grunt-autoprefixer
  Мощнейшая штукень от Андрея Iskin Ситника, сама добавляет нужные браузерные префиксы, с гибким конфигом.

Вроде бы перечислил всё. Свой Gruntfile.js не покажу, потому что он страшный и по большей части слизан с Фоторамы.
Кстати, осторожнее с Grunt, он реально очень быстро вызывает привыкание.

[@Ag47]

Просто для интереса, imgo дает какое-то заметный выигрышь по сравнению с imagemin?

[@GruZZ]

imagemin не пользовался, если честно. Настроек и всяких плюшек у imgo на первый взгляд побольше: github.com/imgo/imgo/wiki/imgo-ru

Хотя надо будет найти время и сравнить их. Возможно, может быть эффективнее их совместное использование в зависимости от размеров и состава картинок.

[@Ag47]

Я тоже так думаю, но есть много ньюансов. На одном проекте пришлось использовать достаточно большие png c прозрачными областями, во второй библиотеке есть чистка прозрачных областей, которая могла бы помочь, а могла бы навредить. Так, что я допустил бы, что, вероятно, существуют как минимум некоторые специальные случаи, когда разница может быть заметна, пускай и не значительная.

С другой стороны, с imagemin никаких проблем замечено не было при установке под различные ос (Win/Ubuntu/OS X), так что эта библиотека легко была внедрена в рабочий процесс у всех наших разработчиков.

[@Fesor]

По сути проще написать простенький плагин, которых будет использовать pngquant и чего еще. Во всяком случае лучше pngquant я пока ничего не нашел для оптимизации PNG. Панда тоже его использует.

[@Ag47]

Не уловил мысль, чем это проще, использования imagemin?

[@Fesor]

Вообще да, ничем… Пойду ка выпью кофе, а то что-то не думается.

[@GruZZ]

Спасибо, про cssrb не слышал.

Плагины нашел: grunt-borschik, grunt-cssrb. Осталось переписать Gruntfile и посмотреть разницу.

Хотя для моих задач лучше, наверное, написать свою технологию для enb или bem-tools, которая бы занималась только экспортом… Но это для меня пока что высшая лига.

[@asheee]

Вот рабочий Gruntfile:
gist.github.com/shuvalov-anton/6505312

Как обычно, что-то писалось в спешке, не судите строго)

[@asheee]

plugins не нужна — исправил. Я по ошибке оставил ее. А что происходит с конфигом можно посмотреть здесь. Я как-то постеснялся весь Gruntfile выкладывать.

[@mishanga]

Если вы используете imgo, рекомендую еще посмотреть на svgo: github.com/svg/svgo

[@Ag47]

Про склейку JS здесь, я так понял, упомянут только concat. Это хорошо, если вообще все надо склеить в один файл, но иногда надо отделить мух от котлет. Во времена ruby, использовал sprockets, который позволял просто склеивать js-файлы, определяя зависимости прямо в них, с помощью специального вида комментариев:

//= require partials/hello

Определять зависимости в файлах оказалось намного удобнее, чем прописывать все файлы для склейки где-либо еще: в Gruntfile.js для concat или в шаблоне, как в usemin, с помощью таких конструкций

<!-- build:js js/app.js -->
<script src="js/app.js"></script>
<script src="js/controllers/thing-controller.js"></script>
<script src="js/models/thing-model.js"></script>
<script src="js/views/thing-view.js"></script>
<!-- endbuild -->

Для, скажем так, веб-приложений, имеет смысл, наверное, смотреть в сторону grunt-contrib-requirejs и r.js, но это зачастую слишком громоздко для большинства стандартных сайтов.

В итоге наткнулся на barkeep и rig, со вторым все получилось сразу и просто, так что использую его.

Приблизительный таск в Gruntfile.js

rig: {
  compile: {
    options: {
      banner: '/* Copyright 2013, XXXXX */\n',
      footer: '\n/* End of source */'
    },
    files: [{
        expand: true,
        cwd: '<%= path.development %>/scripts',
        src: '{desktop,mobile,lib}.js',
        dest: '<%= path.temp %>/scripts'
      }]
  }
}

Комментарии в файлах имеют вид

//= partials/_imagemap.js
//= partials/_player.js
//= partials/_video.js

[@neochief]

Ссылку на книгу-то дадите?

[@asheee]

Держите