Информатор–оповещатель

Когда я только–только заинтересовался системой сборки, оптимизации, проверки и упаковки разрабатываемого сайта gulp, установил её у себя и начал с ней «играться», мне постоянно попадались примеры, в которых использовался плагин gulp–notify и демонстрировались его возможности по выводу на экран компьютера сообщений о ходе выполнения задач — оповещения об удачном или неудачном завершении, произошедшей ошибке и т.п.

Когда же я принял судьбоносное решение об использовании в качестве базового прототипа сборник задач gulpfile.js из пакета WebStarterKit, там ничего похожего на процедуры дополнительного оповещения не обнаружилось. По здравому размышлению, я пришёл к мысли, что особой острой необходимости в в таких процедурах (например, gulp–notify), вроде бы, нет: «глоток» самостоятельно и интенсивно выводит на экран консоли достаточное количество сведений о процессах, которые происходят при выполнении инициированных задач. Однако, совершенно очевидно, что такое положение дел не в полной мере соответствует представлениям о комфорте работы: разработчик вынужден постоянно наблюдать за экраном, не побоюсь этого слова, таращиться в монитор, при том, что в некоторых случаях работа задачи может растянуться на довольно продолжительное время. Кроме того, если уж взялся автоматизировать процесс разработки, то нужно идти до конца, то есть, упрощать себе, любимому, работу по максимуму, создавая всяческие удобства по тому же самому максимуму.

В общем, я бы тоже охотно и радостно попользовал бы плагин gulp–notify, чтобы просто и незатейливо передать в операционную систему команду, которая выведет на экран нужное мне сообщение. Но в моём случае решение оказалась невозможнім: чтобы использовать функционал gulp–notify с Windows, операционка должна иметь версию не ниже восьмой, то есть, моя Windows XP, а также некоторые другие версии помоложе моей (Vista, Win7) оказываются «лишними на этом празднике жизни».

Надежда забрезжила, когда оказалось, что этот плагин можно «прикрутить» к системе оповещения Growl. Я быстренько установил себе «рычалку» (вольный перевод английского growl), но что–то там не заладилось и скрипты никак не хотели выдавать долгожданные сообщения: то ли я что–то не так настроил, то ли просто они (плагин или Growl) меня невзлюбили (я, действительно, бываю порой неприятным). Недолго думая, решил сменить и плагин, и «рычалку».

Оказалось, что gulp–notify при работе «в тандеме» с Growl использует плагин node-notifier, и я решил «припасть к истокам», то есть, обратиться к первоисточнику. Поскольку мой предыдущий негативный опыт взаимодействия с Growl ещё был свеж в памяти, и горючие слёзы разочарования не высохли на упитанных ланитах, я обратил внимание на возможность вызова с помощью этого плагина всплывающей подсказки из системного лотка, широко известной среди пользователей винды как WindowsBalloon. Для этого, правда, требовалась дополнительная программа notifu — бесплатная утилита из двух не требующих инсталляции файлов (notifu.exe и notifu.pdb для 32–битных систем, notifu64.exe и notifu64.pdb для 64–битных; каждая пара размером около 4,5М).Но, оказалось, что эта утилита поставляется вместе с пакетом node-notifier (потому–то он и «весит» в общей сложности 10М).

Итак, взял я рекомендованный пример и попробовал «проиграть» его на примере задачи JShint (проверка корректности сценария Javascript):

var WindowsBalloon = require('node-notifier').WindowsBalloon;
 
var notifier = new WindowsBalloon();

gulp.task('jshint', function () {
    var proc = gulp.src('js/*.js')
        .pipe($.jshint())
        .pipe($.jshint.reporter('jshint-stylish'));

         notifier.notify({
             title: 'GULP JShint',
             message: 'Выполнение задачи завершено',
             sound: true, // При выводе сообщения подаётся звуковой сигнал
             time: 5000, // Сообщение демонстрируется в течение 5 секунд
             wait: false});

    return proc;
});

В правом нижнем углу экрана всплыло жёлтое облачко с текстом в две строки (см. скриншот внизу). И всё бы хорошо, но выполнение задачи при этом остановилось на заказанные пять секунд (или до тех пор, пока я не клацну мышкой по облаку). Вроде бы, директива wait: false (см. строку 16 в приведенном выше фрагменте кода) должна обеспечить завершение работы задачи, независимо от поведения сообщения, но на практике она ждёт и «задерживает очередь». Замена в этой строке false на true не привело к заметному изменению в поведении плагина. В общем, получилось не совсем то, что ожидалось, и комфорта сложившаяся ситуация совершенно не прибавила.

Вместе с тем, мне когда–то попадался на глаза пример вызова внешней команды (а notifu является именно такой внешней командой), поражающий своей простотой и изяществом: используется вызов стандартного метода дочернего процесса (child_process), изначально встроенного в пакет node.js, то есть, никакие плагины не нужны:

var exec_f = require('child_process').execFile;
exec_f('C:\\Program Files\\Accessories\\notifu', 
  ['/p', 'GULP JShint', '/m', 'Работа сценария завершена', '/i', 'info'], 
  {timeout: 250}
  );

что аналогично вызову команды с аргументами:

> notifu /p 'GULP JShint' /m 'Работа сценария завершена' /i 'info'

У этого способа использования системы оповещения есть несколько особенностей. Во–первых, необходимо обзавестись утилитой notifu (я её загрузил с сайта разработчика и поместил в каталоге C:\Program Files\Accessories). Во–вторых, директива timeout: 250 позволяет прервать этот child_process через 250 мс (продолжительность таймаута должна быть кратной 250): в результате, сообщение в жёлтом «облачке» продолжает «висеть» над системным лотком, а выполнение задачи продолжается практически сразу (ну, что такое 250 миллисекунд!). Похоже, удалось обойти досадный баг с wait в node-notifier.

Итак, приемлемое решение было найдено, осталось уничтожить следы неудачных экспериментов, то есть «снести» node-notifier и Growl, после чего твёрдой поступью зашагать в светлое будущее под знаменем notifu.

«Не введи в искушение, но избавь от лукавого» — гласит основная христианская молитва (кстати, единственная рекомендованная Спасителем). Не получилось: и в искушение ввёл, и от лукавого не избавил. А всё потому, что решил я напоследок попробовать, работает ли node-notifier с growl′ом — просто так попробовать, на всякий случай. Попробовал. Работает.

Получилось гораздо выразительнее, красивее и нагляднее — никакого сравнения с notifu

var Growl = require('node-notifier').Growl;

var notifier = new Growl({
  name: 'Growl @ zaliv.info', 
  host: 'localhost',
  port: 23053
});

gulp.task('jshint', function () {
    var proc = gulp.src('js/*.js')
        .pipe($.jshint())
        .pipe($.jshint.reporter('jshint-stylish'));

         notifier.notify({
             title: 'GULP JShint',
             message: 'Выполнение задачи завершено',
             wait: false});

    return proc;
});

Здесь отказ от ожидания реакции пользователя wait: false (см. строку 17) работает исправно, а продолжительность показа сообщения на экране и куча других свойств регулируются уже в настройках Growl. В общем, моё сердце дрогнуло…

А потом я «встретил» growly и понял, что это — судьба. Я таки удалил node-notifier со всеми его десятью мегабайтами разного мотлоха, включая пять подвязанных к нему плагинов, входящих в его зависимости. Потому, что node-notifier для «общения» с Growl′ом использовал именно growly, а я, как уже заметил мой читатель, стараюсь добраться до первоисточников.

Итак, знакомьтесь: конечная цель моих изысканий — плагин growly.

    var growly = require('growly');
    growly.register('GULP @ zaliv.info'); 

    gulp.task('jshint', function () {  
        var proc = gulp.src('js/*.js')
            .pipe($.jshint())
            .pipe($.jshint.reporter('jshint-stylish'));

        growly.notify('Скрипт выполнен', { title: 'JShint'});
 
        return proc;
});

Можно было бы на этом и остановиться, но я ударился в усовершенствования и украшательства — соорудил три иконки для основных типов сообщений и наваял универсальную функцию для вызова «рычалки»:

var growly = require('growly');

growly.register('GULP @ zaliv.info', 'zaliv.png', [
 {label: 'success', dispname: 'Успешно'},
 {label: 'warning', dispname: 'Предупреждение'},
 {label: 'error', dispname: 'Ошибка'}
]); 

function depesha (header, message, mode) {
 var labels = {
   'i': 'success',
   'w':'warning',
   'e':'error'},
  t = new Date();
  
 growly.notify(message, { 
  title: header + " [" + t.toLocaleTimeString() + "]",
  label: labels[mode],
  icon: 'zaliv-' + mode + '.png'  
  })
};

gulp.task('jshint', function () {  
 gulp.src('js/*.js')
  .pipe($.jshint())
  .pipe($.jshint.reporter('jshint-stylish'));
  
  depesha("JShint", "Задача выполнена", "i");
  depesha("JShint", "Есть незначительные погрешности", "w");    
  depesha("JShint", "Ошибка выполнения", "e");
});

В настройках Growl установил «липкий» (sticky) режим отображения сообщений, то есть, они будут болтаться на экране, пока я их сам не закрою — лучше так, чем пропустить что–нибудь, пока на кухне чайком с зефиркой баловался. Получилась такая картина:

Если будет время, можно ещё «пошаманить» с темами в настройках Growl (настроить свою для каждого типа сообщений в зависимости от метки), но это не к спеху.

Настройка на gulpfile.js

Удивительную и несравненную индийскую кухню невозможно представить без экзотических специй: есть у южан масала для овощей, есть для риса, для рыбы, птицы и мяса, есть и масала–чай. Но это не полный перечень многообразий и разновидностей. Дело в том, что каждая хозяйка в каждом доме имеет свой собственный рецепт масалы для овощей, риса, мяса и всего прочего — нередко этот рецепт трепетно и бережно передаётся из поколения в поколение, как в европейских аристократических фамилиях передаётся столовое серебро.

Эти самые масалы прижились и на Ближнем Востоке: в бакалейных отделах супермаркетов можно увидеть ряды, уставленные картонными пачками с готовыми смесями. Впрочем, в арабском мире эти наборы могут иметь и другие имена: например, я охотно пользовался ливанской смесью, называемой «за′атар» (или «загатар», если читать это слово по правилам чтения украинского языка — в арабском тоже есть фрикативный звук «г»). Как бы там ни было, но восточные базары, включая «супербазары» (то есть, супермаркеты) предоставляют достаточный ассортимент специй (например, см. фото в начале статьи), чтобы составить композицию приправ — масалу — на любой, даже самый взыскательный, вкус.

Я, вот, тоже решил замесить свою gulp—«масалу» для автоматизации работы над сайтом, но приступил к работе не с чистого листа, а разбирая и отлаживая уже имеющийся файл сценариев gulpfile.js из весьма неплохого набора WebStarterKit 0.5.2 от Google.

Первым делом, пришлось откорректировать набор плагинов, которые я с энтузиазмом нахватал в период первого знакомства с gulp′ом. На перенастройку ранее сложившейся конфигурации пакета меня побудил доселе неизвестный загрузчик плагинов, который в наборе сценариев gulpfile.js выглядел так:

var gulp = require('gulp');
var $ = require('gulp-load-plugins')();

$.useref();

Оказалось, что этот инструмент загружает (в базовом gulpfile) 17 плагинов, имена которых начинаются с «gulp» — вроде бы, ничего особенного, но при изменении набора этих самых плагинов (удалении ненужных и добавлении необходимых), они неизменно будут «подтягиваться» в скрипт по списку установленных пакетов, имеющихся в из package.json. А вызывается загруженный с помощью этого загрузчика плагин как некий метод: в приведенном выше примере вызывается плагин gulp-useref.

По умолчанию, gulp-load-plugins загружает плагины, соответствующие маске «gulp-*», но эту маску можно изменить. Разработчики рассматриваемого gulpfile.js, по какой–то причине, не стали этого делать и часть плагинов загружают «руками», то есть, путём явного указания имён. Не вдаваясь в причины подобной избирательности, я решил следовать той же тактике (по крайней мере, пока).

В дальнейшем, после вдумчивого и неторопливого сравнения моего первичного перечня плагинов и предлагаемого гугловскими экспертами, мой файл gulp–настроек (package.json) обогатился такими приобретениями:

• gulp–cache — создание промежуточного временного файла;
• gulp–changed — отслеживание изменённых файлов;
• gulp–csso — оптимизация и минимизация CSS–файлов;
• gulp-if — управление выполнением задачи по условию;
• gulp-jshint — проверка файлов сценариев Javascript на наличие ошибок;
• gulp-replace — замена строки;
• gulp-size — вывод сведений о размере проекта или составляющих его файлов;
• gulp-useref — редактирование ссылок на используемые ресурсы (css, javascript) с учётом изменений конечных имён файлов;
• jshint-stylish — дополнение к плагину gulp-jshint, позволяющее выводить разработчику более содержательные описания выявленных ошибок;
• psi — тестирование компонентов проекта и вывод подробной информации о проекте;
• run-sequence — запуск нескольких задач gulp последовательно или параллельно.

Оказались невостребованными шесть плагинов из упоминавшихся в гугловском файле сценариев:

• apache-server-config, gulp–flatten и opn — плагины установлены (имеются в файле конфигурации package.json), но не упоминаются в базовом gulpfile.js, то есть, нет практической надобности в их использовании;
• browser-sync — дублирует функциональность gulp-livereload;
• require-dir — подключает файлы из указанной в аргументах папки, но пока подключать нечего;
• gulp-ruby-sass — дублирует функциональность Scout.

Кроме того, из первоначального набора, составленного при установке gulp, удалены пакеты:

• gulp-autoprefixer и gulp-sass — дублируют функциональность Scout;
• gulp-browserify, gulp-notify и gulp-util — не нашлось применения.

А ещё угроза удаления нависла над плагинами из первоначального набора, которые, похоже, дублируют утилиты из нового набора (WebStarterKit):

• gulp-concat и gulp-rename, похоже, дублирует gulp-useref;
• gulp-filesize — gulp-size;
• glob вроде бы, нигде не используется, но вдруг пригодится….

Интеграция и кооперация

Несомненно, интегрированная среда разработчика (IDE — Intregrated Development Environment) штука хорошая, можно сказать, замечательная. Как правило, под такой средой понимается единая программа, объединяющая в себе и редактор для написания кода, и компилятор, и систему сборки, и отладчик — потому она и называется интегрированной. Вообще–то, особых проблем с её освоением и использованием быть не должно: можно даже подстроить отдельные компоненты под свои личные префернции с помощью плагинов. Но как быть, если уже привык к некоторому набору инструментов, не только идеально подстроив–настроив, а и отшлифовав–отполировав каждый из них? Перспектива перехода на любую «классическую» IDE воспринимается как замена мягких и уютных бурок на стариковских ногах стильными кожаными туфлями на модном, но некомфортном каблуке.

Вот и возникает противоречие: с одной стороны, чтобы всё срабатывало само собой («механизация и автоматизация в действии»), а с другой стороны, сердце кровью обливается от грядущего расставания с отдельными приложениями, столь милыми сердцу, глазам и прочим органам.

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

Свою «кооперативно–интегрированную» среду для работы с сайтом я начал строить на Notepad++ и «джентльменском наборе» Денвер (веб–сервер Apache, СУБД MySQL, интерпретатор PHP и много других утилит, локально имитирующих стандартную службу хостинга). Строго говоря, текстовый редактор и пакет веб–процессинга никак между собой не связаны, то есть, не интегрированы, но в ближайшее время и с неизбежностью мировой революции будут скооперированы: все усилия по интегрированию или псевдоинтегрированию направлены на решение светлой задачи — добиться незамедлительного и автоматического отображения в браузере любых изменений в компонентах веб–страницы (html, css, php, javascript, изображения jpeg, png, gif), большая часть которых производится именно в текстовом редакторе.

Крайние элементы «пазла» обозначены, теперь нужно выстроить цепочку из правильно подобранных промежуточных компонентов.

Если начинать движение от Блокнота, то к нему уже «прикручен» интерпретатор–преобразователь SASS: и сама система установлена (вернее, клон этой системы, без Ruby, — Scout), и плагин, обеспечивающий интерфейс редактора с интерпретатором.

Следующий элемент цепочки — gulp, система сборки проекта, который «подхватывает» изменённые файлы (в том числе и созданный Скаутом), обрабатывает их в соответствии с моим набором инструкций и посылает сигнал Огнелису о необходимости перегрузить страницу. Браузер распознаёт этот сигнал благодаря предусмотрительно установленному расширению и запрашивает обновлённую версию страницы у веб–сервера. Апач, входящий в состав Денвера (вот мы до него и добрались) выполняет запрос, и перед глазами изумлённого разработчика — ай, шайтан! — возникает то, чего он добивался (или же нечто совершенно неожиданное — в случае ошибки).

Ключевым элементом в этой цепочке на текущий момент оказался Гульп: всё остальное уже настроено и работает на благо любимого сайта. Поскольку автор статьи не располагает кривой козой (нормальной козы, кстати, тоже нет), то возможности объехать проблему на этом сомнительном транспортном средстве не предвидится, по крайней мере, в обозримом будущем. Таким образом, задачу приходится решать.

В качестве отправной точки я выбрал гугловский «стартовый пакет разработчика», который тоже использует Gulp. Итак, начинаю читать документацию и разбираться в его устройстве и функциональности по старому детскому принципу: откручивать кукле голову, чтобы увидеть внутренности.

Собственно говоря, начальный пакет разработчика содержит набор шаблонов и инструментов, который способен полностью заменить HTML5Boilerplate и Bootstrap, хотя команда Google тактично и дипломатично оставляет решение об отказе от этих двух пакетов (и переходе на их продукт) на усмотрение разработчика, то есть, вполне допускает некий симбиоз. Для меня же объектом первостепенного интереса в гугловском наборе является предлагаемый файл–сценарий gulpfile.js: именно в него я и полез с зубилом, молотком, сверлом и плоскогубцами.

Большое средство малой механизации

Да здравствует лень — величайший двигатель прогресса! Именно благодаря лени древний человек изобрёл колесо и приручил лошадь, не менее ленивые представители населения планеты изобрели и компьютеры. Это, так сказать, эпохальные проявления нежелания самостоятельно выполнять монотонную или тяжёлую работу. Есть и более скромные, но не менее полезные результаты «ленивых» изощрений: застёжка–«молния», пылесос, «крутилка» суши–роллов (как на картинке в начале статьи), гель для бритья, джин, поиск и замена в текстовых редакторах… Вот, только, растворимый кофе напрасно изобретали…

Да и веб–технология, собственно, сформировалась в угоду ленивому пользователю, а затем процесс и разработки сайтов разделился на дизайн, вёрстку, программирование и продвижение благодаря лени разработчиков: нашёлся способ спихнуть часть работы и пригрузить ближнего.

Меня тоже частенько накрывает плотной мягкой и тёплой волной ленивости: при малейшем удобном случае стремлюсь автоматизировать рутинные повторяющиеся операции и сформировать максимально комфортную среду для работы. В этой статье речь пойдёт о «малой механизации» в работе с таблицами стилей (CSS) и сценариями–скриптами (JS и jQuery). И выбор пал на систему сборки, оптимизации, проверки и упаковки всего перечисленного добра (и не только!) под игривым названием «Хрюк» (по–английски Grunt) — согласитесь, мечта лентяя (и в смысле функциональности, и, некоторой степени, в смысле названия).

Название подтверждается логотипом системы — изображением злобного клыкастого кабана: даже секачу, похоже, не нравится, что разработчик свинячит, а животине разгребать.

Почти сразу образовалась альтернатива «злобному хрюку»: аналогичный пакет и даже с немного похожим английским названием — Gulp. Не то, чтобы я испугался свирепой кабаньей хари, но гораздо ближе по духу оказался «глоток» (по–английски gulp): и с кофе удачно ассоциируется (см. логотип справа), и поновее «хрюка», и те же функции реализованы на более прогрессивной концепции.

Также, как и в случае использования «хрюка», установка «глотка» начинается с установки Node.js — платформы, использующей V8 (движок Google Chrome, исполняющий сценарии Javascript) для запуска скриптов вне браузера. Ничего особенного в процессе установки пакета в Windows нет — запускаешь node-v0.10.33-x86.msi и отвечаешь на типовые вопросы, возникающие при инсталляции любой программы.

Следующий шаг — установка собственно Gulp, и для этого (а также последующей установки gulp–плагинов) используется встроенный в Node.js менеджер пакетов — npm (Node Package Manager). Сначала «гульп» устанавливается глобально. Для этого нужно перейти в каталог проекта, то есть, в папку, в которой будут размещены все ресурсы, из которых Gulp будет «собирать» компоненты для сайта и создать там файл package.json при помощи команды init, ответив на пошаговые вопросы. Если вдруг возникнет чувство неудовлетворённости простотой решения, файл package.json можно сварганить «руками» с использованием текстового редактора.

npm init
npm install --global gulp

Затем этот же пакет нужно установить локально — не спрашивайте, зачем нужна эта двойная инсталляция:

npm install --save-dev gulp

После этого в папке проекта устанавливаются все необходимые для полного счастья gulp–плагины:

npm install --save-dev <имя_плагина>

Я собрал для себя такую «коллекцию»:

• beepbeep — включение системного звука (аргументы задают количество и продолжительность сигналов);
• del — удаление файлов;
• glob — выбор файлов по шаблону (например, *.js);
• gulp-autoprefixer — добавление префиксов для адаптации CSS–файлов для использования с браузерами, поддерживающими собственный синтаксис (аналогично тому, как это делает Compass);
• gulp-browserify — сборка исходных файлов со скриптами в один js–файл с контролем корректности синтаксиса языка программирования;
• gulp-concat — «склеивание» исходных файлов в единый файл;
• gulp-filesize — определение размера файла;
• gulp-imagemin — минимизация файла изображения JPG, PNG. GIF и SVG;
• gulp-livereload — обновление страницы в браузере;
• gulp-minify-html — мнимизация HTML–файлов;
• gulp-notify — вывод сообщения;
• gulp-plumber — предотвращение прерывания потока (pipe) при возникновении ошибки;
• gulp-rename — переименование файлов;
• gulp-sass — преобразование SASS/SCSS–файлов в CSS («конкурент» фреймворка Compass, уже развёрнутого на моём компьютере);
• gulp-sourcemaps — формирование «карт» объединённых файлов для возможности последующей отладки;
• gulp-uglify — минимизация js–файлов;
• gulp-uncss — удаление из CSS–файла стилей, не используемых в проекте;
• gulp-util — вспомогательные функции (вывод сообщения, обработка ошибок, замена расширения файлов и т.п.);

Должен заметить, что некоторые плагины у меня не инсталлировались из виртуальной машины (я использую VMWare Player 6.0.1 build-1379776): попытки установить gulp-uncss, gulp-sass и некоторых других пакетов появлялись «ругательные» сообщения такого вида:

Проблему оказалось довольно просто обойти путём инсталляции тех же пакетов из основной системы (дерево моих проектов доступно и из основной, и из виртуальной систем).

Что касается формирования файла заданий gulpfile.js, который управляет работой Гульпа, то я нахожусь в самом начале пути, поэтому не буду изображать из себя гуру, копируя многочисленные рекомендации и примеры, которые сам нашёл в Сети. Но готов делится с громадой всеми удачными и ошибочными достижениями в этой области — следите за рекламой!

А начать решил с настройки автообновления страницы сайта: при изменение какого–либо из «контролируемых» файлов, состояние страницы в браузере должно немедленно и без дополнительной команды, то есть, самостоятельно обновляться. Для этой цели существует плагин gulp-livereload, но он, похоже, должен работать в тандеме с мини–сервером, предоставляемым другим плагином. Я пытался разобраться в этой спарке, но с налёта у меня не получилось, а долго ломать голову желания не возникло. Поэтому очень кстати оказалось одноимённое расширение к моему браузеру (Mozilla Firefox 34.0). Там же, такое же «удовольствие» имеется и для Google Chrome, и для Safari. Есть такое же расширение и для IE, но придётся разбираться с его установкой, потому что, например, на официальном «мозиловском» сайте предлагается расширение старой версии (и неизвестно, какая версия потребуется для IE).

// Файл gulpfile.js
var gulp = require('gulp'),
    refresh = require('gulp-livereload');

gulp.task('monitor', function(){
  refresh.listen();
  gulp.watch('css/*.css', ['css'])
      .on('change', refresh.changed);
})

Этим скриптом запускается встроенный в gulp-livereload сервер, а встроенная в gulp утилита наблюдения за изменениями файлов (gulp.watch) начинает следить за этими самыми изменениями.

С практической точки зрения, сначала запускается из командной строки задача слежения:

> gulp monitor

а потом, активируется плагин браузера для окна, в которое загружена наблюдаемая страница (на скриншоте внизу красной стрелкой помечено расположение кнопки включения–выключения плагина и показан внешний вид кнопки при включённом и выключенном расширении).

P.S. Менее, чем через месяц предложенный список gulp–плагинов претерпел существенные изменения.