Gulp — Помогите с GULP


Содержание

Скринкаст по Gulp

Gulp — замечательная система сборки и задач, но при всём обилии информации в интернете о ней — это, как правило, либо самые основы, либо «готовые решения», чтобы адаптировать которые нужно понимание, как что работает.

В этом скринкасте я постараюсь восполнить этот «недостающий фрагмент». Не просто «вот такой код работает», а «почему и как он работает», и как его получить. Это сделает использование готовых решений легче и приятнее. И позволит создавать свои.

Для работы с Gulp необходимо знание Node.JS.

Хотя бы выпуски 1-9 (основы), 13 (события), 23-25 (потоки), а желательно – и остальные выпуски первой части скринкаста по Node.JS.

В скринкасте используется новый Gulp версии 4.

Текущей версией является Gulp 3, и большинство руководств в интернете посвящены именно ему.

Однако в новой версии многое сделано более правильно, она обратно совместима и стабильна. Поэтому мы будем использовать её.

В репозитории Gulp есть ветка 4.0, в которой есть и сам код и документация и даже рецепты, уже адаптированные под Gulp 4. Так что на новой версии Gulp вы будете точно не один.

Gulp для ускорения разработки

Что такое Gulp, зачем он нужен, его возможности, как установить и как начать использовать в разработке сайтов. Обновление до Gulp 4

Gulp — что это такое и зачем он нужен

Gulp — это инструмент, позволяющий ускорить процесс web-разработки. Gulp автоматически выполняет все самые необходимые часто используемые задачи.

  1. Автоматическая перезагрузка страницы при сохранении кода
  2. Использование препроцессоров для CSS (например, Sass), для JavaScript (например, CoffeeScript), для HTML (например, Pug)
  3. Минификация CSS, JavaScript, HTML (уменьшение размера кода путём удаления ненужных символов и пробелов)
  4. Соединение файлов в один (например, из пяти CSS файлов сделать один файл CSS)
  5. Создание , удаление и переименование файлов и папок проекта
  6. Автоматическое создание вендорных префиксов (-webkit, -moz, -o, -ms), чтобы старые версии браузеров поддерживали все css-свойства
  7. Оптимизация изображений
  8. И многое другое.

Как установить Gulp глобально в системе

Для установки Gulp нам понадобится пакетный менеджер npm , который входит в состав Node.js . С помощью npm мы будем устанавливать пакеты в каталог node_modules . Если Node.js не установлен, то устанавливаем его. Далее можно начать установку Gulp.

Открыть командную строку и ввести следующий текст:

Коротко о том, что это значит:

  • npm — это менеджер пакетов, с помощью которого будем устанавливать Gulp
  • i (install) — означает установка
  • gulp — это установка Gulp
  • -g (global) — установить глобально, а не в какую-то конкретную папку

Gulp установлен глобально. Приступим к установке Gulp в папку проекта.

Установка Gulp в папку проекта

При создании папок будущего проекта важно помнить следующее: все папки проекта должны быть написаны латинскими буквами, никаких русских символов не должно быть, это необходимо для корректной работы.

Создадим корневую папку для нашего проекта. Назовём, например, gulp-project . Зайдём в неё, зажмём клавишу shift и выберем в контекстном меню пункт Открыть PowerShell здесь или Открыть окно команд .

Введём следующий текст для создания файла package.json .

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

Начнём создание файла package.json

Вводим имя проекта, описание и автора, остальные пункты оставить по умолчанию, нажатием клавиши «Enter». Ответив на все вопросы, будет создан файл package.json.

Теперь мы можем установить Gulp в наш проект, а именно в папку gulp-project , которую мы создавали для нашего проекта.

Для установки Gulp в нашу папку воспользуемся командой:

Есть несколько отличий от установки Gulp глобально.

Здесь нет -g , т.е. Gulp будет устанавливаться локально в ту папку, в которой была открыта консоль. И появилась запись —save-dev, благодаря этому пакет и его версия будет добавлен в package.json. Это нужно для последующей быстрой установки пакетов в других проектах путём копирования файла package.json

После установки gulp мы увидим примерно следующее:

Мы установили Gulp в нашу папку gulp-project , в которой появилась новая папка node_modules . В ней и находится Gulp, а так же будут храниться все зависимости нашего проекта.

Так же если зайти в package.json , то увидим изменения:

Создание структуры Gulp проекта

Структура может быть практически любой, но я рекомендую именно такую, она наиболее распространённая:

    gulp-project/
      app/
        css/ fonts/ img/ js/ libs/ sass/
      • index.html

      dist/ node_modules/ gulpfile.js

    • < >package.json
  • app/ — рабочая папка проекта, в ней будут находиться все исходники — шрифты, изображения, css и js файлы.
  • dist/ — папка продакшена, в ней будет находиться готовый оптимизированный проект
  • node_modules/ — папка с модулями и зависимостями
  • gulpfile.js — файл конфигурации, в котором будем описывать все задачи Gulp
  • package.json — файл, содержащий информацию о проекте (название, описание, автор и т.д.)

Как создавать задачи (таски) Gulp

Создадим файл gulpfile.js и начнём его заполнение.

Сначала нужно подключить Gulp к проекту. Для этого нужно ввести переменную и присвоить ей имя пакета, который находится в папке node_modules. Для этого напишем следующий текст:

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

Gulp таск имеет следующий вид:

[‘имя-другого-таска’] или gulp.parallel(‘имя-другого-таска’) — это необходимо писать в том случае, если до выполнения нашего таска нужно выполнить другой таск(и).

Создадим простейший task, который будет выводить строку ‘Привет, Мир!’.

‘output’ — имя таска, оно может быть любым.

Для вызова таска нужно выполнить команду gulp имя-таска (в нашем случае output ). Сделаем это.

Запуск gulp таска по умолчанию

Таск будет выполнять все перечисленные в ней таски одной командой gulp

И теперь чтобы запустить наш таск, достаточно просто написать gulp

В нашем примере указан один таск, но можно перечислить все необходимые задачи следующим образом:

Это был самый простой пример работы Gulp. Для более сложных задач используются дополнительные методы.

Сборка фронтенда — часть 3. Сборка gulp

В предыдущих частях статьи про сборку фронтенда мы поговорили про основы сборки и написали простое тестовое приложение на backbone + require.js.

Теперь самое интересное — собственно сборка gulp. По ходу статьи мы напишем десяток gulp-задач для различных нужд сборки и подробно разберем, зачем те или иные задачи нужны вообще.

Внимание, это не статья по основам основ gulp! Предполагаю, что Вы знаете, что такое nodejs и npm. Если не знаете, то лучше предварительно погуглите, что это такое и как это все поставить. Установка nodejs, npm и gulp займет у Вас 5-10 минут. А теперь к самой статье.

Мое рабочее окружение

По некоторым причинам мне приходится работать со старой версией nodejs. Поэтому версии плагинов gulp из моего package.json могут отличаться от Ваших. Советую не лениться и не запускать npm install с моим package.json из исходников, а устанавливать все плагины руками, благо, что нужные инструкции в статье будут.

Все версии плагинов, указанные в исходниках, работают на таком окружении:

  • os — windows7
  • nodejs — 0.10.35
  • npm — 1.4.28
  • gulp — 3.9.1


package.json и gulpfile.js

Это первое, с чего мы начинаем сборку фронтенда — создадим package.json в корне проекта.

Стандартная заготовка, можно ничего не менять. После этого ставим gulp. Если он еще не установлен глобально, то делаем npm install -g gulp

Затем устанавливаем gulp как локальную зависимость для нашего проекта — npm install gulp —save-dev. Опция —save-dev обновит package.json, добавив в него секцию

Теперь создадим пока что пустой файл gulpfile.js, тоже в корне проекта, и приступим к задачам сборки. Начнем с базового — с очистки результатов предыдущей сборки.

gulp-clean — удаление файлов и папок

Как мы помним, собранные файлы будут складываться в папку build в корне проекта (на самом деле мы наследим и в src, но зачем и где — чуть позже). Поэтому перед каждым запуском сборки нужно очищать результаты предыдущей — то есть просто сносить папку build.

Ставим плагин gulp-clean — npm install gulp-clean —save-dev. А в gulpfile.js пишем такой код

Сначала мы объявляем переменные-модули, выполняющие всю работу. Пока это сам gulp и clean, но с каждой задачей раздел будет расширяться.

Зачем нужен объект path? Дело в том, что задач у нас будет много, также будет много путей к файлам и папкам. И их удобнее хранить в одном месте, в конфиге, а не разбрасывать по отдельным gulp-таскам. Сейчас объект небольшой, да еще и с пустыми полями, но по мере написания каждой задачи мы будем добавлять в него новые пути и он очень быстро разрастется. Как Вы уже догадались, в build будут пути к стилям, скриптам и картинкам, уже собранным для продакшена, в src — для разработки, в watch — тоже для разработки, файлы для наблюдения за ними, чтобы запускать задачи сборки в режиме онлайн. Но обо всем по порядку.

Сама gulp-таска в конце собственно и очищает папку build. Попробуйте сейчас создать эту папку, кинуть туда пару файлов и запустить в консоли gulp clean. Убедитесь, что после отработки задачи папки исчезла — то, что нужно.

gulp-sass — собираем стили

Ставим плагин gulp-sass: npm install gulp-sass —save-dev. Теперь сама задача. Давайте договоримся, что пока будем собирать стили для режима девелопера. Как мы помним, в предыдущем уроке мы так и не подключили стили к проекту, хотя и написали sass-модули. Пора это исправить. Дополним раздел var вот так:

Добавим пути к нашему конфигу:

Все просто: указываем, что начальный файл main.scss, который уже подключает в себе все дополнительные sass-модули. А также скажем, что положить выходной файл css мы хотим в папку src/styles. Называться он будет так же, как и sass-файл, только с нужным расширением — main.css.

И сама gulp-таска sass

Теперь запускайте в консоли gulp sass, убедитесь, что main.css создался и обновите страничку проекта в браузере. Если все сделали правильно, то стили применятся, появятся отступы по бокам страницы и поправятся шрифты — все хорошо.

Так как main.css у нас собирается автоматически, то нет нужды держать его в проекте, нужно удалять его при запуске gulp clean. Поэтому обновим конфиг:

Теперь запустите снова gulp clean и убедитесь, что удаляется не только папка build, но и файл main.css.

gulp-sourcemaps — sourcemaps для стилей

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

Что это такое? Мы пишем стили для проекта в sass-файлах. Когда мы захотим отладить верстку, то откроем браузерный dev tools, поправим стили, как нужно и захотим их сохранить в проекте. Вот здесь-то нас и подстерегает неудобство. Стили собраны в один-единственный файл. Хорошо нам с тестовым приложением, где 3 строчки стилей лежат в двух файлах, а как быть со стилями, которые собираются из хотя бы полусотни sass-файлов? Для этого и нужны sourcemaps — эти файлы-«карты ресурсов» «запоминают», какие стили в каких исходных sass-файлах находятся. Что конечно же значительно облегчит работу с версткой.

Чтобы было совсем наглядно, вот два скриншота, как мы ищем, где лежат стили для тега h1. Вот здесь мы собрали стили не зная о sourcemaps: Заметьте, мы ничего не знаем о том, где стили для h1 искать в нашем проекте. А вот как выглядит dev tools, когда мы подключим sourcemaps Заметили разницу? Видно, что стили для h1 лежат в первой строке файла _page.scss. А ниже указаны для body — файл _common.scss — удобно. Надеюсь, если Вы до этого не знали про sourcemaps, то теперь точно захотите ими пользоваться :-)

К тому же создавать их с помощью gulp очень просто. Ставим плагин npm install gulp-sourcemaps —save-dev. Пара изменений в gulpfile.js

На заметку: sourcemaps с таким же успехом применяются и при склеивании/сжатии js-файлов, так что пользуйтесь этим инструментом на полную. А мы переходим к сборке модулей requirejs в один файл. Если Вы не знакомы с подходом requirejs, то можете просто пропустить следующий раздел.

gulp-requirejs — сборка require.js

Начиная с этого раздела мы наконец-то вспомним, что сборка фронтенда в первую очередь задумана для боевого окружения, поэтому займемся amd-модулями requirejs. Все модули нужно собрать в один файл да еще сжать его и выкинуть в папку build/js с названием build.js. Здесь долго пояснять не буду, сборку мы разобрали в предыдущей части, когда писали тестовое приложение.

Ставим плагин gulp-requirejs npm install gulp-requirejs —save-dev. Подключаем его:

Прописываем новые пути в path

И самое хитрое — задача gulp-requirejs и конфиг для нее

Подробно объяснить здесь сложно, нужно знать принципы подключения requirejs и внимательно следить за путями к файлам и папкам. Если Вам лень в этом разбираться, то можете просто использовать этот готовый конфиг и по мере надобности понемногу в нем ковыряться.

Почему requirejs:build? Потому что для подключения собранного файла нам нужно будет сначала подключить библиотеку require.js в index.html, и поэтому мы сейчас напишем таску requirejs:copy, которая копирует нужную нам либу в папку build — готовит все для продакшена. Но пока запустите gulp requirejs:build и убедитесь, что сгенерировался файл build/js/build.js.

gulp-contrib-copy — копирование файлов

Теперь нам нужно скопировать файл src/lib.require.js в папку build/js, чтобы все было готово для подключения javascript на странице. npm install gulp-contrib-copy —save-dev Обновляем gulpfile.js

Запустим gulp requirejs:copy_lib и увидим, что в папке build/js/ рядом с build.js появился require.js — значит, все получилось! Идем дальше.

gulp-uglify — сжатие js-файлов

В двух последних задачах requirejs:build и requirejs:copy_lib мы подготовили два файла, предназначенных для боевого окружения. Но хорошим тоном считается сжатие файлов для уменьшения трафика пользователей и ускорения загрузки. В этом нам поможет плагин gulp-uglify.

Ставим. npm install gulp-uglify —save-dev. Сам по себе плагин не используется, он действует совместно с другими задачами, в нашем случае это будет и сборка requirejs:build, и копирование библиотечки requirejs:copy_lib. Поправим код

Посмотрим, что мы изменили. Кроме стандартного подключения, мы добавили всего лишь одну строку .pipe(uglify()) к нашим задачам непосредственно перед формированием выходных файлов. Теперь запустите обе gulp-таски снова и проверьте, что в build/js/ лежат те же файлы, только уже минифицированные — и это пригодно для продакшена. Переходим к последней на сегодня задаче сборки javascript — посмотрим, как работает плагин gulp-concat

gulp-concat — склеивание файлов

Что и зачем мы собрались клеить? Несмотря на то, что весь js-код мы разбили на amd-модули и собрали с помощью gulp-requirejs, очень часто на проекте возникает необходимость подключить какие-то сторонние скрипты, которые не хочется мешать с основным кодом. Это как правило, скрипты вроде inspectlet и яндекс-метрики, которые в больших количествах любят притаскивать аналитики и маркетологи.

Сложим эти файлы в папке src/scripts, чтобы они не мозолили нам глаза, и будем склеивать их все в один, сколько бы их там ни было, и выкидывать в папку build/js/ под названием scripts.js, предварительно сжав. Ух, какое длинное предложение получилось!
Наши действия: создадим папку src/scripts и создадим в ней для примера 3 файла, google-analytics.js, inspectlet.js и shoppyboom.js. Их содержимое незатейливо:

Установим плагин npm install gulp-concat —save-dev. И теперь gulpfile.js

Все достаточно просто. Указываем исходную папку, из которой будут браться все js-файлы, склеиваться в один под названием scripts.js, сжиматься и выкидываться в папку build/js/ уже третьим и последним по счету js-файлом для продакшена. И конечно же, запускайте gulp scripts и проверяйте, что файл действительно есть с содержимым

Мы вплотную подошли к тому, чтобы запустить наше приложение в production-режиме. Но до этого осталось сделать еще одну важную задачу — оптимизацию и сжатие изображений.

gulp-imagemin и imagemin-pngquant — оптимизация и сжатие изображений

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

Установка npm install gulp-imagemin —save-dev и npm install imagemin-pngquant —save-dev. Но здесь хочу обратить Ваше внимание. Именно с этими плагинами у меня прошло не все так гладко. С моей старой версией ноды 0.10.35 согласились работать плагины только с версиями 2.1.0 и 4.1.2 соответственно.

Пробуйте сначала ставить их, как обычно, последние версии по умолчанию. Если Вы столкнетесь проблемой сборки, в консоли будут сыпаться gulp ошибки при сборке или даже при установке. И тогда придется с гуглом наперевес искать подходящие под Вашу ноду версии оных плагинов. Ставить их придется с указанием конкретной версии, вот так npm install gulp-imagemin@2.1.0 —save-dev. Второй плагин аналогично. При этом в package.json имеет смысл убрать ^ из версии плагинов, то есть

Иначе когда Вы захотите обновить версии всех плагинов и запустите npm install, то рискуете обновиться и поломать сборку картинок. А затем долго и нудно возвращать старые версии. Впрочем, будем надеяться, что с Вашей адекватной версии ноды все прекрасно установится и по умолчанию. Редактируем gulpfile.js

Если с плагинами все хорошо и все сделали правильно, то запуск gulp img соберет нам все картинки (всю одну) и выкинет в build/img/ в сжатом виде. Проверяйте. А мы меж тем переходим к самой интересной на мой взгляд теме — препроцессинга html и окончательному формированию production-окружению.

gulp-preprocess — препроцессинг html

На самом деле, плагин умеет препроцессить не только html, но и js, что тоже бывает очень полезно. Но в нашем случае мы рассмотрим только html. Давайте поставим плагин, дабы не забыть про него, и затем разберемся, а что же такое препроцессинг и зачем он нужен.
npm install gulp-preprocess —save-dev

Представим, что у нас настроены задачи для генерации двух вариантов css-файлов: сжатых (для production) и обычных с sourcemaps (для development). А еще мы в режиме разработки не хотим подключать упомянутые ранее js-файлы скриптов, но хотим их на production. А если мы разрабатываем SPA и общаемся с сервером через api, то адреса серверов могут быть различными. Например, на боевом сайте мы обращаемся к серверу по запросам вида webdevkin.ru/api/v1/, но параллельно работаем над новой версией api и тестируем ее на test.webdevkin.ru/api/v2/.

Все эти варианты сводятся к тому, что например, главный html-файл в разных режимах будет пусть и парой строк кода, но различаться. Каждый раз помнить об этом и руками менять нужные строки скучно и чревато ошибками, потому и придумали препроцессинг. Мы готовим шаблон-заготовку html-файла, прогоняем его через задачу препроцессинга и на выходе получаем файл с нужными настройками. Смотрим на примере.

Создадим папку html в src и перенесем в нее файл index.html. Это будет заготовка html, в которой мы чуть поправим содержимое body.

Ничего сложного нет, для режима разработки development мы подключаем require.js из папки lib, а для production — из js. Напомню, что src и build у нас — это корневые папки проектов. И файлы js в них располагаются в разных местах. Плюс для production подключим дополнительно js/scripts.js, которые не нужны нам в разработке.

Надеюсь, ситуация и полезность такого подхода немного проясняется. Осталось сделать так, чтобы эта html-заготовка превратилась в валидный html-файл. В этом нам поможет плагин gulp-preprocess.
npm install gulp-preprocess —save-dev
Добавляем задачу в gulpfile.js

Что мы сделали? Добавили пути в конфиг, указали корневые папки обоих проектов, для src еще указали, где хранится исходный html-шаблон. Не забыли включить генерируемый src/index.html в задачу очистки. build/index.html специально не включаем, папка build и так удаляется целиком. И написали 2 задачи препроцессинга: html:dev и html:prod.

Эти 2 задачи отличаются друг от друга только установкой окружения NODE_ENV и выходными путями, куда складывается преобразованная html. Запустите по очереди gulp html:dev и gulp html:prod и увидите, что в папках src и build соответственно появились index.html с разным, нужным нам содержимым.

Итак, js-скрипты подключаются так, как нам нужно. Но не будем забывать про стили, ибо собранный файл main.css нужно подключать из разных папок: src/styles и build/css. Заменим строку подключения стилей в srс/html/index.html на

Пути к стилям мы указали правильно, но у нас есть только одна задача sass, которая собирает несжатый main.css в src/styles да еще и генерирует sourcemaps. Это отлично для разработки и никуда не годится для боевого сайта. Давайте это исправим. Сначала добавим путь к стилям в build

А затем вместо задачи sass создадим две: sass:dev и sass:prod.

Видим, что для сборки development ничего не поменялось, кроме названия. А вот dev:prod существенно отличается: мы не генерируем в ней sourcemaps, зато сжимаем выходной файл опцией . Как обычно, проверяйте, что все работает, gulp sass:dev и gulp sass:prod.

Теперь когда мы научились препроцессить html, собирать стили, скрипты и requirejs-модули, копировать файлы и оптимизировать изображения, мы переходим к кульминации статьи — собираем все написанные задачи вместе.

gulp develop и gulp production — запускаем сборку одной командой

Мы написали уже с десяток задач под разные окружения, но не собираемся же каждый раз вбивать все их руками. Не для этого же придуманы инструменты сборки. Нет, нам понадобятся всего две задачи, gulp develop и gulp production, которые сами разберутся, какие задачи нам нужно выполнить для нужного окружения. Привожу сразу код и все встанет на свои места.

Все! По запуску одной команды мы сгенерируем все нужные файлы для разработки или деплоя на продакшен. В режиме development нам достаточно только препроцессить html и собрать стили. В production делаем все — и препроцессинг, и стили, собираем модули requirejs в один файл, еще и копируем библиотечку require, а также оптимизируем изображения и склеиваем и копируем файлы scripts.

gulp-sync — запускаем задачи синхронно

Это небольшое отступление от темы. Мы только что написали задачи develop и production, которые запускают множество мелких задач. Природа gulp-a такова, что в таких случаях все задачи запускаются асинхронно. И это здорово, положительно сказывается на скорости работы, если бы не одно но.

Есть задачи, которые должны выполняться только последовательно. В нашем случае, в первую очередь должна отработать очистка предыдущих результатов, и только потом запускаться все остальные таски. gulp умеет делать это нативными средствами, но не очень удобочитаемыми, поэтому воспользуемся сторонним плагином gulp-sync.
npm install gulp-sync —save-dev
И поправим код gulpfile-a


Немного поправили задачи develop и production. И теперь мы уверены, что clean не очистит нам уже возможно сгенерированные другими задачами файлы.

gulp-watch — собираем в режиме онлайн

Написанные задачи отлично подходят для запуска сборки в режиме production. Но для разработки все же чего-то не хватает, а именно. Когда мы поменяем пару строк в sass-файлах или в index.html, нам придется запускать gulp sass:dev, gulp html:dev или gulp develop. Каждый раз врукопашную это делать совсем не интересно. Для этой рутинной работы существует замечательный плагин gulp-watch. Он следит за изменяемыми нами файлами и автоматически запускает нужные задачи сборки. Посмотрим, как это работает.

npm install gulp-watch —save-dev
Правим код

Казалось бы, сложная задача, которая сэкономит нам уйму времени, но так легко и быстро настраивается. Всего лишь указали, за какими файлами мы хотим следить и какие задачи запускать при их изменении. Обратите внимание, мы добавили задачу watch в develop. Теперь gulp develop не только соберет стили и html для разработки, но и запустить задачу их автоматической пересборки — отлично!

Для проверки запускаем gulp develop и пробуем редактировать, например, sass-файлы. В терминале сразу увидите, как gulp реагирует на Ваши действия и запускает задачу sass. То же самое и с html. Параллельно проверяте содержимое src/styles/main.css и src/index.html и убеждайтесь, что их содержимое меняется.

browser-sync — запуск локального веб-сервера

И напоследок рассмотрим очень крутую штуку, легко позволяющую поднять локально веб-сервер. Я упоминал, что для проверки работы Вам нужно было настроить apache или nginx, или запустить сервер средствами IDE, или заливать файлы на хостинг. С помощью этого плагина наш проект становится совершенно самодостаточным. Всего лишь одна команда позволит запустить проект в нужном режиме, development или production. То есть из двух разных папок, src или build. Давайте поставим плагин и проверим на примере.
npm install browser-sync —save-dev

Мы создали конфиги для веб-сервера, указав разные корневые папки и порты, а также написали собственно задачи для запуска webserver:dev и webserver:prod. webserver:dev мы еще добавили в задачу develop. Проверим, что из этого получилось.

Запустите теперь gulp develop и немного подождите. У Вас откроется браузер, где в новой вкладке по адресу http://localhost:9001 откроется наш проект, запущенный из папки src. Откройте консоль и убедитесь, что это действительно режим разработки: стили и скрипты не сжаты, 3 файла scripts не загружены, для стилей есть sourcemaps. При этом в фоне работает watch, и если Вы поменяете стили, то переключившись в браузер и обновив страницу, Вы сразу увидите сделанные обновления. Просто отлично!

Получается, теперь все что нам нужно, чтобы начать работать — это запустить gulp develop. Остальное все сделается за нас: очистятся результаты предыдущей сборки, соберутся стили и html, запустится наблюдатель watch и веб-сервер. Да еще и откроется браузер с запущенным проектом.

В режим production я не стал включать webserver:prod — мы собираем для продакшена не чтобы запустить браузер, а чтобы собрать файлы и залить их на боевой сайт. Но убедиться, что все собрано правильно и корректно работает, смысл имеет. Сделайте сначала gulp production, а затем gulp webserver:prod. Проект из папки build запустится с адресом http://localhost:9001.

Открыв dev tools, Вы легко проверите, что подключились именно продакшеновские файлы, сжатые стили и скрипты, никаких sourcemaps. Также заметите 3 отдельных js-файла из папки scripts, которые сыпят в консоль сообщения ‘init что-то там’.

Дополнение: browserSync.reload

Грамотный человек в комментариях (Dima) напоминает про одну замечательную вещь: browserSync.reload. Иными словами, liveReload, живая перезагрузка. Настроив ее, нам больше не придется обновлять страницу в браузере руками, после правки кода она перезагрузится сама. И сделать это очень просто.

Допустим, мы хотим обновлять страницу при изменении html, стилей, javascript-кода и шаблонов в папке tpl. Конечно, только в режиме develop. Для этого в таски html:dev и sass:dev нужно дописать одну строчку — .pipe(browserSync.reload())

Для js-кода и шаблонов делаем чуть по-другому. Добавим пути к отслеживаемым файлам в конфиг path.watch и одну строку в watch-таску

Перезапускайте gulp develop и пробуйте редактировать код, страница обновляется, кодить стало намного приятнее.

browserSync tunnel

Хочется упомянуть еще об одной небольшой детали насчет browserSync. Откройте терминал и увидите примерно такую картину Обратите внимание на строку
Tunnel: http://pjwhpjlsom.localtunnel.me
Она означает, что прямо сейчас Ваш проект доступен по этой ссылке извне. Можно отправить ее коллеге-программисту или дизайнеру. Конечно, это работает только до тех пор, пока у Вас запущен веб-сервер. При следующем запуске адрес поменяется: удобно и безопасно.

Выводы, исходники проекта и нужные ссылки

На этом пока все, что я хотел рассказать о сборке фронтенда с помощью gulp. Статья получилась объемной, много кода, но и написали мы немало самых разных задач. Материал получился очень сжатым, но подробный рассказ о рассмотренных плагинах и вариантах сборки мог бы растянуться на десяток статей.

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

gulp, как, например, и git, относится к таким инструментам, без которых в принципе можно обойтись. Код они за нас не напишут. Но после знакомства с ними ты уже не можешь представить, как жил и работал до этого. Они становятся настолько привычными, что любой проект ты начинаешь с создания репозитория и настройки сборки. И только когда все подготовительные операции пройдены, ты со спокойной душой начинаешь заниматься программированием.

Исходники проекта доступны по этой ссылке. Желаю удачной сборки и отличных проектов! Вопросы, пожелания и критику оставляйте в комментариях.

Установка и использование Gulp

Установка Gulp

Установка Gulp довольно простая. Для начала установите пакет Gulp глобально:

Затем установите его в свой проект:

Использование Gulp

Давайте создадим задачу Gulp для минимизации одного из наших файлов JavaScript. Создайте файл с именем gulpfile.js. В нём будут определяться ваши задачи, которые запускаются с помощью команды gulp.

Добавьте следующие команды в ваш файл gulpfile.js:

Установите gulp-uglify через npm выполнив npm install —save-dev gulp-uglify , а затем запустите задачу через gulp minify . Предположим, у вас есть файл с именем app.js в папке js, новый app.js будет создан в папке build и содержать сжатую версию js/app.js.

Что на самом деле здесь происходит?

Мы делаем несколько вещей в нашем файле gulpfile.js. Вначале мы загружаем модули gulp и gulp-uglify:

Затем определяем задачу с именем minify, которая при запуске вызывает функцию, заданную в качестве второго аргумента:

В конце, и это самое сложное, мы определяем, что наша задача должна делать:

Если вы не знакомы с потоками, а большинство фронтенд-разработчиков с ними не знакомы, то код выше ничего вам не скажет.

Потоки

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

В приведённом выше примере функция gulp.src() получает строку, которая соответствует файлу или набору файлов, и создаёт поток объектов представляющих эти файлы. Затем они переходят (или перетекают) в функцию uglify() , которая принимает объекты файлов и возвращает новые объекты файлов с минимизированным исходником. Этот результат затем перетекает в функцию gulp.dest() , которая сохраняет изменённые файлы.

Вот что происходит в виде схемы:

Когда есть только одна задача, функция ничего не делает. Тем не менее, рассмотрим следующий код:

Чтобы запустить это самостоятельно, установите gulp, gulp-jshint, gulp-uglify и gulp-concat.

Эта задача берёт все файлы соответствующие js/*.js (иными словами все файлы JavaScript из папки js), запускает для них JSHint, выводит отчёт, минимизирует каждый файл, а затем объединяет их, сохраняя их в build/app.js. В виде схемы:

Если вы знакомы с Grunt, то заметите, что это довольно сильно отличается от того, как работает Grunt. Grunt не использует потоки. Вместо этого он берёт файлы, запускает одну задачу для каждого файла и сохраняет в новые файлы, повторяя весь процесс для каждой задачи. В результате множества обращений к файловой системе, Grunt работает медленнее, чем Gulp.

Для лучшего понимания потоков прочтите Stream Handbook.

gulp.src()

Функция gulp.src() берёт один или несколько файлов или массив и возвращает поток, который может быть передан в плагины.

Gulp использует node-glob для получения указанных файлов. Проще всего объяснить на примерах:

  • js/app.js
    Соответствует определённому файлу.
  • js/*.js
    Соответствует всем файлам, заканчивающихся на .js в папке js.
  • js/**/*.js
    Соответствует всем файлам с расширением .js в папке js и всех вложенных папках.
  • !js/app.js
    Исключает js/app.js из соответствия, что полезно если вы желаете выбрать все файлы в папке за исключением определённого файла.
  • *.+(js|css)
    Соответствует всем файлам, заканчивающихся на .js или .css.

Другие функции также доступны, но в Gulp они обычно не применяются. Посмотрите документацию Minimatch ради подробностей.

Предположим, у нас есть папка с именем js, содержащая файлы JavaScript, некоторые минимизированы, а некоторые нет. Мы хотим создать задачу по минимизации ещё не уменьшенных файлов. Чтобы сделать это, мы выбираем все файлы JavaScript в папке, за исключением всех файлов, оканчивающиеся на .min.js:

Определение задач

Чтобы определить задачу используйте функцию gulp.task() . Для простой задачи эта функция принимает два параметра: имя задачи и функция для запуска.

Запуск gulp greet выведет «Здравствуй, мир» в консоли.

Задача также может быть списком других задач. Предположим, мы хотим определить задачу build, которая выполняет три других задачи: css, js и imgs. Мы можем сделать это, указав вместо функции массив с задачами:

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

Теперь, когда вы запустите задачу css, Gulp выполнит задачу greet, подождёт, пока она окончится, а затем вызовет указанную функцию.

Задача по умолчанию

Вы можете определить задачу default, которая выполняется, когда вы просто запускаете gulp. Вы можете сделать это, определив задачу с именем default.

Плагины

Вместе с Gulp вы можете использовать ряд плагинов — более 600 на деле. Вы найдёте их список на странице плагинов, либо путём поиска gulpplugin в npm. Некоторые плагины помечены «gulpfriendly»; это не плагины, но они предназначены для работы с Gulp. Учтите, что при поиске непосредственно в npm, вы не увидите плагины из чёрного списка (прокрутите страницу с плагинами вниз и увидите больше).

Большинство плагинов довольно просты в использовании, имеют хорошую документацию и запускаются аналогичным образом (через поток файловых объектов). Они, как правило, модифицируют файлы (хотя некоторые, вроде валидаторов, нет) и возвращают новые файлы, которые передаются в следующий плагин.

Давайте расширим уже упомянутую задачу js:

Мы используем три плагина: gulp-jshint, gulp-uglify и gulp-concat. Вы можете увидеть в файлах README для плагинов, что их довольно легко использовать. Доступны некоторые настройки, но по умолчанию, как правило, всё хорошо.

Вы, возможно, заметили, что плагин JSHint вызывается дважды. Потому что первая строка вызывает JSHint для файлов, которые только присоединяют свойство jshint к файловым объектам без какого-либо вывода. Вы можете прочитать свойство jshint самостоятельно или передать его в jshint.reporter по умолчанию или в другой reporter , такой как jshint-stylish.

Два других плагина понятнее: функция uglify() минимизирует код, а функция concat(‘app.js’) объединяет все файлы в один с именем app.js.

gulp-load-plugin

Модуль, который я нахожу весьма полезным называется gulp-load-plugins, он автоматически загружает любые плагины Gulp из файла package.json и присоединяет их к объекту. Основное применение следующее:

Вы можете записать всё в одну строку ( var plugins = require(‘gulp-load-plugins’)(); ), но я не большой поклонник однострочного вызова require.


После запуска этого кода объект plugins будет содержать ваши плагины с именами в CamelCase-стиле (к примеру, gulp-ruby-sass будет загружен как plugins.rubySass ). Вы можете использовать их обычным путём. Например, наша задача js сократится так:

К этому прилагается файл package.json, который содержит нечто похожее:

Данный пример на самом деле не намного короче. Однако для объёмных и сложных Gulp-файлов, это сократит блок с загрузкой файлов до одной или двух строк.

Версия 0.4.0 gulp-load-plugins выпущенная в начале марта добавила отложенную загрузку плагина, которая улучшает производительность. Плагины не загружаются, пока их не вызовем, это значит, что вам не придётся беспокоиться о неиспользованных плагинах в package.json влияющих на производительность (хотя их, вероятно, следует убрать в любом случае). Другими словами, если вы запустите задачу, которая требует только два плагина, она не станет загружать все плагины, которые необходимы для других задач.

Отслеживание файлов

Gulp имеет возможность следить за изменением файлов и выполнять задачу или задачи при обнаружении изменений. Эта функция удивительно полезна (для меня, наверное, одна из самых полезных в Gulp). Вы можете сохранить Less-файл, а Gulp превратит его в CSS и обновит браузер без каких-либо действий с вашей стороны.

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

Предположим, что у нас есть задача build, она превращает наши файлы шаблонов в HTML и мы хотим определить задачу watch, которая отслеживает изменение шаблонов и запускает задачу для преобразования их в HTML. Мы можем использовать функцию watch следующим образом:

Теперь при изменении файла шаблона будет запущена задача build, которая создаст HTML.

Вы также можете указать для watch функцию обратного вызова вместо массива задач. В этом случае функция получает объект event содержащий информацию о событии, которое вызвало функцию:

Другой отличительной особенностью gulp.watch() является то, что она возвращает watcher . Используйте его для прослушивания дополнительных событий или для добавления файлов в watch. Например, чтобы одновременно запустить список задач и вызвать функцию, вы можете добавить слушателя в событие change при возвращении watcher :

В дополнение к событию change вы можете прослушивать ряд других событий:

  • end
    Срабатывает, когда watcher завершается (это означает, что задачи и функции обратного вызова не будут больше вызываться при изменении файлов).
  • error
    Срабатывает, когда происходит ошибка.
  • ready
    Срабатывает, когда файлы были найдены и готовы к отслеживанию.
  • nomatch
    Срабатывает, когда запросу не соответствует ни один файл.

Объект watcher также содержит некоторые методы, которые можно вызывать:

Gulp — установка и запуск плагина gulp-uglify

August 20, 2014

В предыдущей статье “Gulp — знакомство и первый запуск”” мы познакомились с установкой менеджера Gulp и запуском первой задачи под него. В этой статье мы перейдем к еще более интересному материалу, в котором узнаем, как устанавливать и запускать плагины под Gulp на примере одного из них — gulp-uglify.

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

Каждый из плагинов — это код, решающий только одну задачу. Например, один плагин умеет сжимать изображения, другой сжимает js-файлы, третий сжимает css-файлы; еще один умеет компилировать scss-файлы в css-файлы. И так далее — список можно продолжать и продолжать.

Становиться понятно, что для конкретной задачи нам нужно установить нужный плагин и создать задачу (task) в файле . А затем запустить Gulp на выполнение этой задачи. Конечно, задач может быть не одна, а несколько. Все зависит о того, какие именно задачи нам необходимо выполнять.

Давайте рассмотрим процесс установки плагинов и настройки задач на примере одного из них — . Данный плагин служит для минификации js-файлов — он удаляет пробелы, запятые, точки с запятой. В результате js-файл получается меньшим по размеру.

Все плагины под Gulp размещены по этому адресу — Gulp Plugins. В строке поиска нужно вводить имя искомого плагина, в результате получаем (или не получаем) страницу с описанием плагина и командой для его установки.

Устанавливаем gulp-uglify под Gulp

На странице плагина gulp-uglify описана команда установки этого плагина, которую мы повторим для себя, в своем проекте:

Опять таки, ключ “говорит” менеджеру добавить плагин в качестве зависимости в файл :

Создаем задачу gulp-uglify под Gulp

Плагин установлен и теперь самое время прописать в файле именованную задачу (named task) под него. Надеюсь, уважаемый читатель помнит о двух типах задач под Gulp, описанных в предыдущей статье “Gulp — знакомство и первый запуск”.

Открываем файл в редакторе кода (у меня это Sublime Text) и вносим туда следующие строки:

В принципе, можно и не вводить вышеприведенные строки вручную, а просто скопировать их со страницы описания плагина gulp-uglify. Они размещены в блоке с заголовком Usage.

Но это не главное. Важнее разобраться, что из себя представляет каждая из этих строк. Так вот, строка — это создание переменной с именем , в которую помещается плагин . Обратите внимание на синтаксис этой строки и ее табуляцию — оба аспекта важны и их несоблюдение приведет к тому, что Gulp не будет работать. По большому счету, можно написать и так — , но предыдущая запись является более правильной.

Далее идут строки для новой именованной задачи для Gulp. Имя задачи задаем произвольно и пусть оно будет таким — . В теле callback-функции пропишем директорию, содержимое которой Gulp должен отслеживать — . В данном случае указываем, что Gulp должен следить за изменениями всех файлов с расширением .js, расположенных внутри директории .

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

Вот мы и разобрали суть задачи в Gulp! Ведь ничего сложного, правда?!

Запускаем задачу gulp-uglify в Gulp

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

Вуаля! Видим (по аналогии с предыдушим опытом запуска дефолтной задачи), что именованная задача успешно запустилась, выполнилась за 12 миллисекунд и также успешно завершилась. По идее, теперь по пути у нас должен располагаться минифицированный js-файл (в моем случае это был ).

Посмотрим и видим, что так оно и есть, файлик помещен туда, куда мы и прописывали:

А точно ли он минифицированный? Это легко проверить — открываем его в Sublime Text и наблюдаем такую картину:

Полезные плагины под Gulp

Мы успешно установили и запустили плагин под Gulp — можно в очередной раз поздравить себя! В данном случае это был плагин для минификации js-файлов.

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

Ниже я приведу примерный список наиболее полезных плагинов под Gulp, существующих на сегодняшний день:

  • // минификация HTML-файлов
  • // минификация CSS-файлов
  • // еще один плагин минификации CSS-файлов
  • // минификация JS-файлов
  • // компиляция SCSS-файлов в CSS-файлы
  • // компиляции SCSS-файлов в CSS-файлы, более стабильный
  • // конкатенация (соединение нескольких файлов в один файл)
  • // .
  • // запуск плагина LiveReload
  • // мониторинг файлов в фоновом режиме в Gulp
  • // вывод окна с уведомлением о событиях в Gulp
  • // сжатие изображений в Gulp
  • // переименование файлов в Gulp
  • // настройка обработки ошибок в Gulp

gulpgulp-uglify

RxJs — map

Первый «серьезный» метод в моей RxJs-копилке знаний. На самом деле все просто — этот метод получает на вход поток, обрабатывает каждый ev. … Continue reading

ТИПИЧНЫЙ ВЕРСТАЛЬЩИК

Современная Frontend разработка предполагает использование препроцессора стилей SCSS или LESS, препроцессора и шаблонизатора HTML — Pug, сжатие изображение, JS и CSS файлов, в целях оптимизации загрузки веб-страниц и многоe многое другое. Чтобы упросить этот процесс, мы предлагаем вам воспользоваться сборкой проектов Gulp 4, которую постоянно совершенствует Андрей Горохов. Ниже будут представлены ссылки на скачивание, а пока пройдемся по основным моментам: описанию и установке.

Сборщик проектов Gulp

Gulp — это сборщик проектов, инструмент для автоматизации задач, которые описаны выше. Он поможет вам ускорить вашу работу и грамотно подготовить проект к релизу.

Скачать сборку можно с репозитория Github или через командную строку Git. В дальнейшем вы сможете настроить её под свои задачи.

Особенности

  • именование классов по БЭМ
  • используется БЭМ-структура
  • используется препроцессор SCSS
  • используется транспайлер Babel для поддержки современного JavaScript (ES6) в браузерах
  • используется Webpack для сборки JavaScript-модулей
  • используется CSS-сетка smart-grid на основе Bootstrap для быстрой адаптивной вёрстки
  • используется жёсткий кодгайд

Установка

  • установите NodeJS (если требуется) и Yarn
  • скачайте сборку с помощью Git: git clone https://github.com/andreyalexeich/gulp-scss-starter.git
  • установите gulp глобально: yarn global add gulp-cli
  • перейдите в скачанную папку со сборкой: cd gulp-scss-starter
  • скачайте необходимые зависимости: yarn
  • чтобы начать работу, введите команду: yarn run dev (режим разработки)
  • чтобы собрать проект, введите команду yarn run build (режим сборки)

Если вы всё сделали правильно, у вас должен открыться браузер с локальным сервером. Режим сборки предполагает оптимизацию проекта: сжатие изображений, минифицирование CSS и JS-файлов для загрузки на сервер.


Если у тебя возникли проблемы с установкой, то посмотри этот ролик:

Файловая структура

  • Корень папки:
    • .babelrc.js — настройки Babel
    • .bemrc.js — настройки БЭМ
    • .eslintrc.json — настройки ESLint
    • .gitignore – запрет на отслеживание файлов Git’ом
    • .stylelintrc — настройки Stylelint
    • .stylelintignore – запрет на отслеживание файлов Stylelint’ом
    • gulpfile.babel.js — настройки Gulp
    • webpack.config.js — настройки Webpack
    • package.json — список зависимостей
  • Папка src — используется во время разработки:
    • БЭМ-блоки: src/blocks
    • шрифты: src/fonts
    • изображения: src/img
    • JS-файлы: src/js
    • страницы сайта: src/views/pages
    • SCSS-файлы: src/styles
    • HTML-файлы: src/views
    • конфигурационный файл веб-сервера Apache с настройками gzip (сжатие без потерь): src/.htaccess
  • Папка dist — папка, из которой запускается локальный сервер для разработки (при запуске yarn run dev )
  • Папка gulp-tasks — папка с Gulp-тасками

Команды

  • yarn run lint:style — проверить SCSS-файлы. Для VSCode необходимо установить плагин. Для WebStorm или PHPStorm необходимо включить Stylelint в Languages & Frameworks — Style Sheets — Stylelint (ошибки будут исправлены автоматически при сохранении файла)
  • yarn run lint:style —fix — исправить ошибки в SCSS-файлах
  • yarn run dev — запуск сервера для разработки проекта
  • yarn run build — собрать проект с оптимизацией без запуска сервера
  • yarn run build views — скомпилировать Pug-файлы
  • yarn run build styles — скомпилировать SCSS-файлы
  • yarn run build scripts — собрать JS-файлы
  • yarn run build images — собрать изображения
  • yarn run build webp — сконвертировать изображения в формат .webp
  • yarn run build sprites — собрать спрайты
  • yarn run build fonts — собрать шрифты
  • yarn run build favicons — собрать фавиконки
  • yarn run build gzip — собрать конфигурацию Apache

Рекомендации по использованию

Компонентный подход к разработке сайтов

  • аждый БЭМ-блок имеет свою папку внутри src/blocks/modules
  • папка одного БЭМ-блока содержит в себе один HTML-файл, один SCSS-файл и один JS-файл (если у блока используется скрипт)
    • HTML-файл блока импортируется в файл src/views/index.html (или в необходимый файл страницы, откуда будет вызываться блок)
    • SCSS-файл блока импортируется в файл src/blocks/modules/_modules.scss
    • JS-файл блока импортируется в src/js/import/modules.js

Пример структуры папки с БЭМ-блоком:

Чтобы вручную не создавать соответствующие папку и файлы, достаточно в консоли прописать команду bem create my-block — для создания папки БЭМ-блока, где my-block — имя БЭМ-блока

Страницы проекта

  • страницы проекта находятся в папке src/views/pages
    • главная страница: src/views/index.html

Шрифты

  • шрифты находятся в папке src/fonts
    • используйте форматы .woff и .woff2
    • шрифты подключаются в файл src/styles/base/_fonts.scss
    • сконвертировать локальные шрифты можно с помощью данного сервиса

Изображения

  • изображения находятся в папке src/img
    • изображение для генерации фавиконок должно находиться в папке src/img/favicon и иметь размер не менее 1024px x 1024px
    • изображения автоматически конвертируются в формат .webp . Подробная информация по использованию тут.

Сторонние библиотеки

  • все сторонние библиотеки устанавливаются в папку node_modules
    • для их загрузки воспользуйтеcь командой yarn add package_name
    • для подключения JS-файлов библиотек импортируйте их в самом начале JS-файла БЭМ-блока (то есть тот БЭМ-блок, который использует скрипт), например:
    • для подключения стилевых файлов библиотек импортируйте их в файл src/styles/vendor/_libs.scss
    • JS-файлы и стилевые файлы библиотек самостоятельно изменять нельзя

⚠️ Если в вашем проекте используется несколько библиотек, которые необходимо подключать на нескольких страницах, во избежании ошибок нужно:

  • по пути src/js/import создать папку pages
  • в папке pages создать js-файл для страницы, например, pageA.js , и импортировать туда библиотеку, которая будет использоваться только на этой странице
    • аналогично проделать шаг для дополнительных страниц
  • в файле webpack.config.js в точку входа добавить js-файлы страниц, пример:
  • подключить скомпилированные js-файлы на необходимых страницах

В сборщик включена CSS-сетка smart-grid от Дмитрия Лаврика. Она позволяет избавиться от лишних классов в разметке за счёт использования примесей в SCSS и ускоряет адаптивную вёрстку. Конфигурация уже настроена в соответствии с сеткой Bootstrap. Пример использования:

SCSS

Результат

Нужен SCSS + Pug?


Данная сборка постоянно дорабатывается и улучшается, поэтому всю самую актуальную информацию вы найдете в Github репозитории. Будем рады предложениям, пишите их в телеграм чат. Там вы обязательно найдете автора сборки Андрея Горохова.

Простая и быстрая сборка frontend проекта с помощь gulp

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

Сейчас в интернете существует большое число различных сборщиков и подходов к ней, и каждый выбирает для себя что-то по вкусу. Я только опишу вам один из многих подходов, а вы уже решите сами, подходит он вам или нет.

Как уже все догадались, речь пойдет о сборщике под названием Gulp.

Скажу сразу, что у вас должен быть установлен Node.js. У кого не установлен, то вам сюда https://nodejs.org/en/download/

Итак, приступим:

Откроем консоль и создадим папку

mkdir nebo15

Зайдем в папку, которую только что создали

cd nebo15/

запустим команду инициализации проекта:

npm init

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

<
«name» : «nebo15» ,
«version» : «1.0.1» ,
«description» : «first gulp project» ,
«author» : «stranger» ,
«license» : «MIT» ,

В строке dependencies я указал, что нам понадобится gulp и тут же будут появляться все наши плагины.

Основные плагины, с которыми я хочу вас познакомить:

gulp-minify-css — нужен для минимизации CSS кода, создаст один файл *.min.css

gulp-uglify — будет минимизировать наш JS, создаст один файл *.min.js

gulp-autoprefixer — авто-добавление добавляет вендорные префиксы (-webkit, -o, -moz) к CSS свойствам, нужно чтобы ваш код поддерживался во всех браузерах.

browser-sync — понадобится для запуска локального сервера.

gulp-sass — предназначен для компиляции SCSS и SASS кода.

gulp-sourcemaps — предназначен для генерации css sourscemaps, которые понадобятся при отладке кода

//= footer.html эти комментарии будут заменены на код с файла при компиляции

gulp-watch — предназначен для отслеживания за изменениями файлов.

rimraf — для очистки папок по завершению сборки (rm -rf для nodejs).

После установки всех плагинов у нас будет файл package.json:

делается это при помощи команды

npm install name _ of _ package save dev

где —save-dev означает то, что пакет будет остановлен в проект, а не глобально. Для глобальной установки используйте тег -g.

Bower

Сейчас просто не представляю своей жизни без установщика Bower и хочется верить, что вы не исключение. Если же нет, то почитать о Bower можно тут .

Давайте поставим его в наш проект. Для установки напишем в консоли:

bower init

Заполняйте поля те, что знаете, остальное пропускайте. В конце вы получите файл bower.json:

<
«name» : «nebo15» ,
«version» : «1.0.0» ,
«authors» : [
«Dima»
],
«license» : «stranger» ,
«ignore» : [
«**/.*» ,
«node_modules» ,
«bower_components» ,
],

«dependencies» : <
«normalize.css» : «*» ,
«jquery» : «2.*»
>

Установим пакеты с dependencies:

bower i

Давайте создадим базовую структуру и настроим сборку нашего проекта.

Структура проекта:

Сначала нужно 2 папки. Первая (src), в которой мы собственно будем писать код, и вторая (build), в которую сборщик будет собирать файлы.

Текущая структура у нас выглядит так:

В src создали типичную структуру для проекта. Сделаем main файлы в папках js/ и style/ и создадим стартовую index.html страничку такого содержания.

index.html

Структура папки src теперь будет выглядеть так:

fonts —папка с шрифтами

img — папка с картинками

js — папка со скриптами. Тут в корне — main.js, а рабочие файлы в папке partials

style — папка со стилями. Тут в корне — main.scss, а рабочие файлы в папке partials

template — тут будем хранить html код

Все html страницы, которые мы верстаем, будут лежать в папке src

Gulpfile.js

Итак, начнем, сначала подключим все зависимости в этот файл.

Так же создадим js объект, в который пропишем все нужные нам пути, чтобы при необходимости легко в одном месте их редактировать:

Веб сервер

Чтобы иметь livereload, нам необходимо написать себе веб-сервер. Для этого напишем следующую таску

Сборщик для html

Напишем таску для сборки верстки html

Стоить вспомнить, что rigger — плагин, позволяющий использовать конструкцию для подключения файлов:

В папке src/template/ создадим файлы header.html и footaer.html

В папку header.html поместим

В папку footer.html поместим

а файл index.html отредактируем соответственно так:

Запускаем сборку следующей командой

После того, как она соберется, переходим в папку build и увидим там наш файл index.htm

Сборщик для JS

Таска для сборки скриптов будет примерно такая

Зададим структуру для main.js:

Запустим сборку js:

И в папке build/js можно увидеть скомпилированный и модифицированный файл.

Сборщик для стилей


Таска для сборки SCSS:

Здесь все легко, но если вы заинтересовались настройками автопрификсера, то об этом можно почитать тут.

Запустим нашу таску

Теперь давайте определим таску с именем «build», которая будет запускать все:

Отлеживаем изменения в файлах

Чтобы не запускать каждый раз сборщик вручную, давайте попросим gulp при изменении какого-то файла перезапускаться.

Понять это просто. Просто при изменениях какого-то файла происходит пересборка проекта.

Попробуйте запустить в консоли:

Измените что-то в проекте и увидите, что произойдет.

Очистка

Если вы прикрепите большую библиотеку, потом запустите задачу js:build и потом решите, что она вам больше не нужна и удалите ее, то она все равно останется в папке проекта build. Так что было бы удобно периодически удалять ее содержимое. Создадим для этих потребностей простую таску

Теперь, запуская команду с консоли

папка build будет удаляться.

Напоследок

Мы должны определить стандартную таску, которая запустит всю нашу сборку , используя только одну команду.

gulp.task( ‘default’ , [ ‘build’ , ‘webserver’ , ‘watch’ ]);

Запустим в консоли

Вот и все. Теперь вы можете настроить проект для себя. Надеюсь, данная статья оказалась познавательной для вас.

Пример верстки на флексах с использованием gulp и less.

Разработку любого сайта следует начинать с настройки инструментов.

Рассмотрим инструменты и подготовим их к работе.

Все материалы я буду добавлять сюда: https://github.com/pikaweb

Для работы с репозиториями нам пригодится GitBash. Скачать его можно отсюда:

В качестве локального сервера я использую OpenServer:

Кроме того понадобится установить node.js

Перейдем к подготовке. Создаем каталог в \Ваш путь\OpenServer\domains\

Запускаем OpenServer. Входим в его настройки, вкладка «Домены» и добавляем домен для созданной ранее папке. Запускаем сервер.

Теперь сайт будет доступен при вводе в браузере http://domain-name/

Настраиваем git (если еще не настроен). Я предпочитаю bitbucket т.к. он предоставляет бесплатные приватные репозитории. Ниже ссылки на github и bitbucked и на материал по настройке подключения сразу к обоим:

Переходим к созданию git репозитория.

Добавление проекта в репозиторий:

Подробный tutorial по bitbucket:

Настроив репозитории, перейдем к настройке gulp для проекта. Для начала его нужно установить (необходим установленный node.js). Перейдя в терминале (можно и gibush, можно любой удобный для вас) в каталог с сайтом, выполняем следующую команду:

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

npm install gulp —save-dev

—save-dev обозначает, что мы сохраним информацию об установке пакета в package.json. Это нужно, чтобы не хранить в репозитории подгружаемые npm файлы для установленных модулей. Все они содержатся в node_modules. Чтобы node_modules не отправлялись на git, создадим файл .gitignore со следующим содержимым:

А теперь продолжим устанавливать модули для gulp:

Модуль gulp-concat для конкатенации файлов:

npm install gulp-concat —save-dev

Модуль gulp-less для построения css файлов на основе less. Про это чуть подробней при верстке проекта.

npm install gulp-less —save-dev

Для less еще пригодятся less-plugin-clean-css (пост обработка и сжатие less файла) и less-plugin-autoprefix (автоматическое добавление вендорных префиксов, согласно базе данных caniuse.com)

npm install less-plugin-clean-css —save-dev

npm install less-plugin-autoprefix —save-dev

Для сжатия css файлов добавим gulp-minify-css

npm install gulp-minify-css —save-dev

Часть css я встраиваю в html, поэтому добавим gulp-inline-source

npm install gulp-inline-source —save-dev

Для удаления комментариев из html файла понадобится.

npm install —save-dev gulp-remove-html-comments

Для очистки файла от лишних пробелов и удаления комментариев из html файла понадобится:

npm install gulp-htmlclean —save-dev

Для него требуется jquery

npm install slick-carousel –save-dev

npm install jquery —save-dev

Для верстки еще полезно подключить normalize.css или reset.css. Я обычно использую normalize.

npm install normalize.css —save-dev

Почитать про него можно тут:

Продумаем общую структуру проекта

Где в public будет собираться проект.

Для настройки gulp следует создать файл gulpfile.js и подключить в нем все установленные плагины:

var gulp = require(‘gulp’)

var less = require(‘gulp-less’);

var minifyCSS = require(‘gulp-minify-css’);

var inlinesource = require(‘gulp-inline-source’);

var LessPluginCleanCSS = require(‘less-plugin-clean-css’),

cleancss = new LessPluginCleanCSS(< advanced: true >),

var htmlclean = require(‘gulp-htmlclean’);

var concat = require(‘gulp-concat’);

var uglify = require(‘gulp-uglify’);

//generate css from less ( + slick less files + slick files).

return gulp.src([‘./assets/less/*.less’, ‘node_modules/slick-carousel/slick/slick.less’, ‘node_modules/slick-carousel/slick/slick-theme.less’])


plugins: [autoprefix, cleancss]

//move images to public

//inline link, script and img in index.html . Clean html.

return gulp.src([‘node_modules/jquery/dist/jquery.min.js’,’node_modules/slick-carousel/slick/slick.min.js’, ‘assets/js/*.js’])

gulp.task(‘default’, [‘less-to-css’,’index’, ‘slickJs’]);

Запуск gulp осуществляется из консоли. Открыв консоль в каталоге с проектом и введя gulp, мы запустим выполнения задачи default, которая в свою очередь выполнит задачи ‘less-to-css’,’index’, ‘slickJs’. За счет gulp.watch, после любого изменения less файлов или index.html файла будет выполняться соответствующая задача.

Для примера верстки макета я выбрал .psd макет, распространяемый свободно как для некоммерческого, так и для коммерческого использования.

Ссылка на макет:

Из плюсов, к нему сразу прилагаются шрифты и макет демонстрирующий отображение на мобильном устройстве.

Обычно первым делом я формирую общую схему разметки. Получается нечто подобное:

В дальнейшем в разметке я буду придерживаться BEM методологии. Почитать про неё можно здесь:

Далее согласно этой методологии размечаю всю страницу.

Оптимизация загрузки шрифтов.

К данному макету шрифты шли в каталоге /fonts.

Для оптимизации работы со шрифтами воспользуемся fontsquirrel и возможностью хранить до 5мб места в localstorage. Подробней можно прочитать в переводах статей Adam Beres-Deak:

Верстал преимущественно флексами, про них можно почитать по ссылкам:

Ссылка на кросс-браузерный вариант реализации filter.

Полностью выкладывать в пост файлы проекта я не буду. Они выложены в гит аккаунте сообщества:

Посмотреть на результат в git pages:

Чтобы отправить каталог public В новую ветвь для git pages следует выполнить следующую команду:

git subtree push —prefix public origin gh-pages

Если у кого-нибудь будут проекты, которые вы хотите выложить в репозиторий сообщества – пишите. Создам репозиторий и поделюсь доступом.

Дубликаты не найдены

Большое спасибо за пример.
А есть ли что-то еще на флексах с БЭМ, less, gulp и psd макетом? Аналогичное, но более сложное. Возможно с использованием flex-grow/flex-shrink.
Если да, выложите на гитхаб пожалуйста, буду очень благодарен.

На днях думал перевести и выложить перевод этой статьи:

Хороший хак по flex.

Примеров, чтобы сразу показать нет. Если найдете небольшой макет со сложным элементом — могу его сверстать флексами и показать.

а вы можете рассмотреть вариант побыть тьютором?
на один макет средней сложности, помочь с флексами и js.
если да, то как можно связаться, уточнить условия и прочие подробности?

Я не против побыть тьютором, у меня уже есть опыт в этом. Оставьте свой e-mail/skype/vk или любой другой контакт и я вам напишу.

Народ, подскажите пожалуйста, т.к. с версткой особо не дружу, хотя с css3 немного знаком. Я так понимаю PostCss и Scss это препроцессоры css, облегчающие верстку, а что из них лучше учить на данный момент?

С PostCSS лично не знаком, но опираюсь на то, что Bootstrap v4 и Foundation используют именно SASS/SCSS именно как платформу для своих фреймворков.

Почему less, а не sass?

Зачем OpenServer? Где livereload? Почему не используешь плагин для оптимизации изображений?

Чем less-plugin-autoprefix отличается от gulp-autoprefixier?

1. less и scss сопостовимы по возможностям. Точнее scss несколько мощнее, но для данной задачи принципиальной разницы не будет. Мне так привычней, поэтому использовал его.

2. Openserver я использую как локальный сервер. Давно им пользуюсь, удобно стрктурированны прошлые проекты. Для данной задачи он действительно не обязателен. Можно конечно обойтись сервером из npm.

3. На gulp перешел недавно, livereload еще не использовал. Судя по тому, что о нем читал — удобно.

4. Изображения пожал на этапе нарезки макета при помощи FileOptimizer. Какой из плагинов под gulp рекомендуете?

5. less-plugin-autoprefixer — это плагин для gulp-less. Выбрал его т.к. ориентировался на список плагинов с сайта less http://lesscss.org/usage/#plugins

Если есть рекомендации, как улучшить верстку или настройки — с удовольствием почитаю. Особенно если с пояснениями о преимуществах другого подхода.

Frontender Magazine

Недавно появившаяся система сборки gulp внушает большие надежды. Этот инструмент дает возможность всего за 10 минут написать действительно лаконичный код. Часто, одного этого факта вполне достаточно, чтобы противопоставить его более «многословному» Grunt.

Вы ведь помните Grunt? Я достаточно много писал о нем в прошлом, и даже написал книгу, в которой я предложил использовать его как инструмент для сборки. Grunt — потрясающий таск-менеджер, и вы должны как-нибудь обязательно его попробовать.

Некоторые люди считают, что Grunt будет вытеснен gulp, и предрекают последнему множество поклонников. Я же считаю, что это возмутительно и вопиюще нелепо. Хотя это и не так очевидно, но у Grunt есть множество плюсов по отношению к gulp. С другой стороны, у gulp тоже есть свои преимущества по отношению к Grunt.

В этой статье я собираюсь объяснить, что из себя представляет gulp, так как это достаточно новый инструмент, который появился около полугода назад. Затем, я хочу сравнить его с Grunt, чтобы показать, какой из таск-менеджеров что лучше делает и объяснить, почему он это делает лучше.

Введение в gulp

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

Как вы могли заметить в ходе изучения документации, установка gulp очень похожа на установку Grunt:

  • Создаем package.json ;
  • Выполняем команду npm install -g gulp ;
  • Выполняем команду npm install —save-dev gulp ;
  • Создаем gulpfile.js ;
  • Выполняем команду gulp .

В этом месте пока что главное различие с Grunt заключается в том, что gulp не выносит свой CLI из основного модуля. Это может немного запутать вас, если вы не понимаете, как работает установка глобальных модулей в npm .

Перед тем, как мы перейдем к примеру gulpfile.js, давайте разберемся, что из себя представляет API gulp. Оно содержит всего 5 методов. В общем-то, это все, что вам понадобится для работы. Это потрясающе лаконичное API, которое действительно помогает gulp фокусироваться на главном — решении задач, связанных со сборкой проектов.

  • .src(globs[, options]) принимает glob и возвращает входной поток
  • .dest(path) принимает путь к файлу и возвращает исходящий поток
  • .task(name[, deps], fn) определяет задачу
  • .run(tasks. [, cb]) запускает задачу
  • .watch(glob [, opts], cb) следит за изменениями в файловой системе

Должен признаться, на мой взгляд это API просто великолепно! Посмотрим на простую задачу из документации gulp — компилирование Jade-шаблонов. Здесь jade() и minify() — это плагины gulp, я объясню вам принцип работы чуть ниже.

Как видите, тут не так уж и много шаблонного кода. На самом деле, мы пишем довольно простой код вместо того, что бы собирать объект-конфигурацию.

В Grunt же вам, напротив, понадобится именно шаблонный код для той же самой операции: загрузка npm модулей с помощью grunt.loadNpmTasks , создание ссылки на задачу, которая содержит список требуемых тасков, и конфигурация каждой задачи так, как вам нужно. Одна из проблем Grunt, которую решает gulp — это единый монолитный конфигурационный объект, заставляющий вас танцевать с бубном, чтобы достичь желаемых результатов.

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

Помимо всего прочего, лаконичность кода в gulp помогает предотвратить ситуацию, когда конфигурация сборки начинает сбивать вас с толку.

Каков gulp на вкус

Взгляните на этот короткий пример gulpfile.js , взятый из документации.

Согласитесь, это довольно просто прочесть, даже если вы не знакомы с потоковой системой передачи данных в Node.js. Я уверен, что этот файл гораздо легче для восприятия, чем Gruntfile.js , который делал бы аналогичные вещи. В этом примере мне достаточно пробежаться глазами по коду и понять, что происходит. А если вы избавитесь от очевидных комментариев, то вы получите очень краткий gulpfile.js .

Тот факт, что Gulp обеспечивает реализацию метода .watch как часть своего основного API, также не может не радовать, ведь наблюдение за изменениями файлов является ключевой частью функционала систем сборки, оно просто необходима в процессе разработки. Да и поддержка разработки асинхронных задач, кажется, гораздо лучше интегрирована в gulp, чем в Grunt, где цели («targets») действительно усложняют работу при передаче данных в задачи.

В целом, API, которое есть у gulp, обеспечивает более понятное и простое использование, чем API Grunt. Это более-менее весомый аргумент в пользу gulp, имеющего столь простое, лаконичное, потрясающее API. И простые плагины, которые выполняют одну простую задачу, а не делают все, что им может понадобиться, как это принято в большинстве плагинов Grunt. Но, у gulp есть свои недостатки.

Рассекая симбиоз /Gr?u(nt|lp)/

Давайте рассмотрим ситуацию, когда сравнение этих двух таск-менеджеров заходит в тупик. В gulp все основано на потоковой системе передачи данных, как если бы вы писали shell-скрипты. Все в порядке, если вы понимаете, как устроены потоки в Node.js, но если это не так — похоже, что у меня для вас плохие новости.

Итак, если вы хорошо знакомы с Node.js, то вам будет трудно игнорировать ту смелость, с которой gulp строит поток сборки напрямую вокруг кода, вместо предварительной конфигурации, как это делает Grunt. Однако, с другой стороны, это неоспоримый недостаток — некоторые люди просто никогда не поймут механизм потоков в Node. Это могут быть PHP-разработчики, или другие серверные вуду, типа Ruby или Python. Они не обязаны ничего знать о потоках и буферах в Node. Может быть, они немного разобрались в CommonJS, но едва ли они продвинулись в ее изучении дальше своей зоны комфорта. Такие люди вряд ли откажутся от Grunt в пользу gulp.

В то время, как gulp легче для чтения и восприятия, Grunt легче в написании, что порой гораздо важнее.

В целом, gulp ориентирован на сборку, и, в особенности, на работу с файлами. Ключевой принцип API Gulp можно сформулировать как «In, Out, Watch» («Туда, Обратно, Наблюдаем», прим. ред.). Это здорово, потому что позволяет сконцентрироваться на конкретной задаче по проекту, а именно, его сборке. Именно в этом-то и заключается основная идея — вы передаете файл на вход в систему, затем получаете его обратно, и где-то в это же время с файлом происходят нужные вам преобразования. Но у этой краеугольной идеи, заложенной в API, есть очевидный недостаток. Манипуляции, которые не относятся непосредственно к процессу сборки, становятся выполнить гораздо сложнее. Например, отправка уведомления об окончании сборки или запуск Amazon EC2-серверов противоречат тому, для чего был разработан gulp.

Конечно же, gulp очень молод, и мы можем наблюдать, как развивается его экосистема, но я не стал бы ждать, что разработка задач под эту систему будет более популярна, чем под Grunt. Я просто не верю, что gulp может «побить» Grunt в непрерывной интеграции и в области развертки приложений. Но, с другой стороны, gulp может полностью взять на себя более простые процессы, такие как, например, сборка клиентской части и публикация ее на Heroku.

Gulp не переплюнет Grunt

Хотя gulp и может привлечь столь необходимое внимание к таск-менеджерам и расширить границы того, что они сейчас могут, я приведу ниже несколько причин, почему я считаю, что gulp не вытеснит окончательно Grunt. Во-первых, gulp и не собирается вытеснять Grunt. По крайней мере, никто не преследует подобную цель, и уж точно, ее не преследуют лидеры индустрии.

Grunt против gulp: оба служат разным потребностям и могут существовать сообща. Смотрите: http://t.co/fQ5G8HDNwl и https://t.co/joUVeRqj8T. Мы поддерживаем обоих.

Возможно, для вас это и новость, но вряд ли это такой уж сюрприз. В текущую эко-систему Grunt было вложено много усилий, и едва ли хотя бы один из её разработчиков окончательно всё бросит только ради того, чтобы портировать свои наработки и плагины под gulp — пусть и горячего, но все же новичка. Выбор, на самом деле, очень прост — придерживаться того, что у вас уже есть, или бросится в омут по новой, в погоне за популярным и неизведанным.

Во-вторых, как я уже писал ранее, в gulp есть определенный порог входа, которого нет у Grunt. Без опыта в Node.js у вас будут большие трудности с пониманием механизма работы потоков, передачей данных между этими потоками, с буферами, с асинхронным JavaScript в целом, с промисами, коллбеками, да с чем угодно вообще. И, учитывая все эти факторы, я просто не представляю, как gulp может просочиться в среду далеких от Node.js людей и применяться там как система для сборки фронтенда.

Кроме всего вышеперечисленного, Gulp не решает никаких новых проблем. Серьезно. Его API великолепно и целенаправленно, но оно вызывает затруднения в задачах, не касающихся сборки проекта — в этой сфере, безусловно, побеждает Grunt. В npm зарегистрировано больше 2000 плагинов Grunt, в то время как для gulp их написано всего около 200. Интересно наблюдать за экспериментами, в которых gulp запускает задачи Grunt, но я сомневаюсь, что эта практика приживется.

Я не думаю, что симбиоз /Gr?u(nt|lp)/ сделает вашу жизнь легче, вряд ли. Если вам кажется, что вам нужны обе системы сборки, то, вероятно, вам стоит остановиться только на Grunt.

Можно также рассмотреть фактор скорости работы этих систем. Но я предлагаю вам подумать над этим самостоятельно. Более важно, на мой взгляд, понять, что здесь нет единственно верного ответа. Может быть gulp и быстрее, но возможности Grunt могут быть куда более обширными, и, в конце концов, вы отдадите свои предпочтения в пользу одного из таск-менеджеров. Но, ради бога, не используйте оба в одном проекте, не будьте как этот парень.

Только что перешел на проекте с #gruntjs на #gulpjs — код проще и время подготовки билда сократилось с 3-5 сек до 10-20 мс. Я не шучу.

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

Кабанчик как будто уже несвежий

Grunt может потухнуть сам по себе. Он целую вечность находился в версии 0.4.1 , перед тем как сдвинуться к скромной 0.4.2 , а сейчас, кажется, что он вообще никуда не двигается. За все эти дни, практически не было активности в твиттере @gruntjs. Вряд ли это хороший знак.

Я действительно надеюсь, что это такой переходный период, и за кулисами планируется 0.5.0 , но меня не покидает ощущение, что команда разработчиков переключилась на другой проект. Я бы не стал однозначно говорить, что Grunt заброшен, но у меня есть такие опасения, потому что я не вижу, никаких признаков активной работы над ним. Мне действительно очень сильно хочется увидеть релиз версии 1.0.0 , с переосмысленной структурой конфигурации, с учетом тех проблем, о которых мы говорили выше. Хочется увидеть простую загрузку плагинов, встроенный в ядро watch , подобно тому, как это сделал gulp, простую семантическую структуру файлов и более легкую настройку задач в целом.

Конечно, просто хотеть такие штуки замечательно, но вот реализовать их, не сломав при этом большинство из 2000 работающих плагинов, крайне тяжело. Учитывая, что эко-система плагинов в Grunt является одной из его главных ценностей — сформировать разумный план развития приложения становится чрезвычайно сложно. Остается только сидеть и ждать, либо вы можете попробовать выйти вперед и предложить что-нибудь, что вы бы лично хотели видеть в версии 0.5.0 .

Аргументы за то, что бы ничего не делать

Правые Unix-экстремисты снова и снова предлагают перестать плодить сущности, и выкинуть gulp и Grunt из головы. Вот так вот, просто ничего не делать. Я, по правде говоря, не согласен с таким типом экстремизма, но вам может быть более комфортно, если вы напишете все на чистом JavaScript. Я даже думаю, что в этом может быть определенный смысл. Но в данном случае, я считаю, что уже само наличие npm run — достаточный аргументом к существованию gulp.

Да, gulp достаточно близка философия отказа от создания лишних сущностей, но в каких-то моментах он все-таки ближе к Grunt, который, наоборот, весьма далек от этой идеи. Я думаю, разработчики gulp придают значение обеспечению поддержки Windows, хоть это и приносит определенную сложность, так что это действительно компромисс. Вам просто нужно честно спросить себя, что вы ищете. И, если вам нужно что-то действительно очень и очень простое, то вам лучше использовать npm run .

Поддержка Windows вряд ли имеет много смысла, потому что большинство из нас работают на *nix, но это важно для других сообществ, куда Grunt похоже постепенно приходит. Думаю, вы можете использовать кое-что от bash в Windows, но делать там что-то в командной строке — все еще боль. Да и вообще, вряд ли это серьезный аргумент, чтобы не использовать Grunt на Windows.

Что ж, используйте Gulp или Grunt. Да все равно, по большему счету.

Все равно, конечно, но помните

В простоте обучения людей сборке Grunt выигрывает, да и то, его вряд ли легко [понять любому][21], но он проигрывает в лаконичности. В лаконичности выигрывает gulp, у него просто великолепный API. И в то же время, его минус в высоком пороге вхождения, в первую очередь потому, что потоковую передачу данных достаточно трудно понять. В области малых усилий и рисков находится npm run . Он хорош тем, что не плодит лишних сущностей, там вообще нет ничего лишнего. Его очевидный минус в кросс-платформенности, если это для вас важно.

Выбирайте сами. Не стоит принимать решение, основываясь на чьих-то словах. Выбирайте инструмент, который работает для вас. Тот, который вы понимаете, и с которым вам удобно работать. А важнее всего, тот, который делает именно то, что вам нужно. Не делайте выбор вслепую, выбирая наугад, или потому, что кто-то вам что-то рассказал об этом инструменте. Так же, как, например, не стоит застревать, используя монолитные jQuery приложения (это просто аналогия), пробуйте что-то новое! Будьте открыты к инновациям.

Мы сами должны стать теми переменами, которые хотим увидеть в мире. Махатма Ганди

Начинаем работать с gulp.js

Для автоматизации рутинных, повторяющихся процессов мы используем gulp.js. В своем шаблоне мы используем следующие его возможности:

  • компиляция scss в css, jade в html
  • автоматическое проставление вендорных префиксов
  • оптимизация изображений
  • конкатинация скриптов
  • сжатие скриптов и стилей
  • создание иконочных шрифтов и svg-спрайтов
  • проверка html на валидность

Это основные, есть еще несколько мелочей, об этом позже. Шаблон нашей команды вы найдете на гитхабе

Установка

Gulp — это npm-пакет для node.js, поэтому устанавливаем node.js (https://nodejs.org/en/). Устанавливаем как обычную программу.

После установки перейдите в папку с проектом и в консоли введите:

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

После выполнения этой команды вы увидите в вашем проекте папку node_modules. Это папка для хранения npm-пакетов. В данном случае вы установили пакет локально, т.е. все файлы gulp лежат в проеке. Как вы могли заметить это занимает некоторое время. Для того, чтобы не устанавливать каждый раз кучу модулей локально — устанавливайте пакеты глобально, а затем делайте ссылку на них в проекте. Как это сделать:

Мы установили gulp глобально, а затем сделали ссылку в проект. Все команды запускаются из папки проекта.

Далее установим остальные пакеты и слинкуем их:

Сначала я устанавливаю плагины для разработки, потом для сборки. Если у вас возникли проблемы с установкой какого-либо плагина — попробуйте установить его отдельно.

Пишем gulpfile

В корне вашего проекта создайте gulpfile.js. Без этого файла gulp работать не будет. В нем описываются все таски, перечисленные в начале статьи. Сначала необходимо прописать зависимости для проекта.

Обычно в репозитории плагинов есть информация о том, как прописывать зависимость. Далее объявим переменные для папок проекта:

Их будем использовать в тасках. Напишем первый таск — для компиляции jade

Теперь, чтобы скомпилировать jade, достаточно ввести в консоль:

Постепенно вы привыкните к синтаксису. Обычно в репозитории gulp-модуля есть примеры тасков. Обратите внимание на строчку

При возникновении ошибок компиляции будет “вылетать” gulp, и нужно запускать заново. Но с плагином plumber этого не будет. Для того, чтобы перезапускать браузер после каждого прохождения таска используется команда:

Для конкатинации скриптов служит следующий таск:

Он соединит все таски из папки js/all в один скрипт. Обычно это разные плагины.

Таски для синхронизации папок проекта между собой:

Для того, чтобы отслеживать изменения в проекте и запускать таски автоматически используем gulp.watch

Для обновления браузера и локального хоста используем browser-sync

Теперь, чтобы запустить все это хозяйство напишем дефолтный таск gulp

Здесь мы указываем какие таски необходимо запустить вместе. Благодаря таску watch, gulp не закончит работу, а будет ждать изменений.

Для того, чтобы запустить дефолтный таск введите

Откроется браузер и все будет компилироваться и обновляться автоматически.

Цукерберг рекомендует:  Php - Ошибка при загрузке файлов на сервер, как исправить
Понравилась статья? Поделиться с друзьями:
Все языки программирования для начинающих