В последнее время Gulp набирает большую популярность, и понятно почему. Он быстрее, красивее и проще чем Grunt . Мне приходилось часто с ним работать, но я всегда брал готовые решения и не до конца понимал как же он все это делает. На этих выходных я решил разобрать и закрыть эту небольшую проблему. Об этом и поговорим сегодня.
Что такое Gulp?
Gulp - это инструмент сборки front-a. Он позволяет автоматизировать повторяющиеся задачи (сборка и минификация CSS- и JS-файлов, запуск тестов, перезагрузка браузера и другие). Тем самым Gulp ускоряет и оптимизирует процесс веб-разработки.
Установка Gulp
Установить Gulp достаточно легко. Если у вас что-то не получится, пишите в комментариях или загуглите вашу проблему. Итак для установки нужно сделать 3 шага:
- Установить Gulp глобально
- Установить Gulp как devDependencies (зависимости для разработки)
- Создать файл gulpfile.js
Первый шаг - устанавливаем глобально Gulp. Открываем терминал и пишем:
npm install --global gulp
После этого вам нужно установить Gulp как devDependencies для вашего проекта. Убедитесь в том, что у вас есть файл package.json . Если его нет, то создайте его написав в консоль npm init . Теперь можно установить Gulp как devDependencies:
npm install --save-dev gulp
И наконец, вам нужно создать gulpfile.js в корне вашего проекта, который будет содержать ваши задачи (tasks). В качестве промежуточного шага, мы установим плагин gulp-util . Чтобы показать как устанавливаются плагины:
npm install --save-dev gulp-util
Теперь настало время написать нашу первую задачку. Открываем только что созданный файл gulpfile.js и пишем в него следующее:
/* File: gulpfile.js */ // собираем все наши плагины var gulp = require (" gulp " ), gutil = require (" gulp-util " ); // создаем задачку, которая будет выполняться по умолчанию gulp . task (" default " , function () { return gutil . log (" Gulp is running! " ) });
И теперь нам остается запустить gulp в терминале и мы увидим нечто похожее на это:
> gulp [ 12:32:08] Using gulpfile ~/Projects/gulp-scotch-io/gulpfile.js [ 12:32:08] Starting "default" ... [ 12:32:08] Gulp is running! [ 12:32:08] Finished "default" after 1 ms
Обзор
Сам по себе Gulp очень скуден на возможности. Но все, что вам нужно вынесено в отдельные плагины. Они совместно с Gulp творят чудеса.
Api у gulp очень маленькое, и содержит всего 4 функции высшего порядка:
- gulp.task
- gulp.src
- gulp.dest
- gulp.watch
gulp.task определяет наши задачи. В качестве аргументов принимает название, зависимости (массив) и функцию (основные действия). Зависимостей может и не быть:
gulp . task (" mytask " , function () { //сделать что-то }); gulp . task (" dependenttask " , [ " mytask " ], function () { //сделать что-то после того, как "mytask" будет выполнен });
gulp.src указывает на файлы, которые мы хотим использовать. Он использует.pipe доступа к файлам через плагины.
gulp.dest указывает на папку, в которую мы хотим сохранить измененные файлы.
gulp.src и gulp.dest используется для простой копии файлов:
gulp . task (" copyHtml " , function () { // скопировать все html файлы из source/ в public/ gulp . src (" source/*.html " ). pipe (gulp . dest (" public " )); });
В gulp встроена система реагирования на изменения файлов (gulp.watch). Вы можете использовать эту задачу для запуска других необходимых вам задач при изменении файлов.
В те времена, когда сайты были небольшими, необходимости в отдельной сборке фронтенда не было. Однако объем и сложность CSS и JS все увеличивались, и вид, в котором удобно разрабатывать, стал сильно отличаться от вида, в котором нужно показывать результат пользователю. Появились такие задачи, как конкатенация (склеивание) файлов, минимизация кода и даже предварительная компиляция. Результатом этого стали специализированные системы сборки фронтенда, о которых мы и расскажем.
Разумеется, как только необходимость в сборке стала ощутима, тут же на фронтенд начали переползать инструменты, использовавшиеся бэкендом. Основная их проблема и причина того, что в данный момент их все меньше используют для фронтенда, - они совершенно не заточены под его специфику, так как структура проекта, используемые технологии и цикл разработки очень сильно зависят от задач проекта и могут значительно отличаться. Тот же Ant, например, обладает многословным синтаксисом и не особо умеет делать нужные для фронтенда вещи: встроенных задач совсем немного, а расширяется он плохо. Если говорить о GNU make, то он гораздо более универсальный, поскольку оперирует shell-командами. Из недостатков нужно упомянуть об особом синтаксисе, который надо дополнительно изучать, необходимости хорошо знать shell, а также тенденции к быстрому усложнению Makefile при росте требований к сборке.
Давай рассмотрим средних размеров сайт со стандартной структурой и попробуем перечислить основные этапы сборки, которые он проходит. Для простоты предположим, что ты не заморачиваешься с созданием разных JS-файлов для разных страниц, но при этом хочешь держать в девелопмент-окружении несколько небольших файлов, чтобы поддержать какую-никакую модульность. Обычно это выглядит как-то так:
/libs/ jquery.min.js underscore.min.js /js/ common.js carousel.js popups.js ....
Система сборки обычно делает следующее:
- конкатенирует все JS-файлы в один (в нужном порядке, мы же не хотим загрузить наши скрипты раньше, чем jQuery);
- проверяет JS-код на валидность (например, с помощью JSHint);
- минимизирует код, по необходимости его обфусцирует (то есть делает непонятным);
- конкатенирует CSS-файлы (порядок тут тоже важен, так как свойства часто переопределяются);
- минимизирует CSS;
- складывает файлики в отдельную директорию, из которой ты и подключаешь их в своем HTML.
Зачастую эта простая схема усложняется дополнительными требованиями: прогоняются тесты, компилируется код CSS-препроцессоров, оптимизируются картинки, компилируются шаблоны.
Все эти задачи, и даже больше, умеют решать современные инструменты сборки. Будем рассматривать самые популярные решения, которые работают на платформе Node.js. Общим их преимуществом является понятный язык, который знают (или считают, что знают) все фронтенд-разработчики, изначальная направленность на решение задач фронтенда, а также понятное Node.js окружение, в котором ты, может быть, уже разрабатываешь свое приложение.
Grunt
Grunt - самый старый, самый главный и самый популярный инструмент для сборки. Почти все рассматриваемые нами системы сборки так или иначе сравнивают себя с Grunt, а некоторые и возникли как более быстрые или более простые его альтернативы. Несмотря на это, у него есть пара существенных недостатков.
Во-первых, как отмечают многие фронтенд-разработчики, Grunt многословен. На настройку простой системы сборки потребуется конфиг под сотню строк. Впрочем, само по себе это не такой уж недостаток: конфиг читается довольно легко, а в силу популярности Grunt найти уже готовый конфиг под типовую задачу обычно не представляет труда.
Во-вторых, Grunt разрабатывался как универсальный продукт, то есть на его основе можно решить практически любую задачу, связанную со сборкой проекта. Это круто, но за универсальность приходится платить. Как упоминавшейся многословностью, так и скоростью. В сравнении с другими системами сборки на Node.js Grunt заметно медленнее, и, что особенно неприятно, имеет тенденцию замедляться по мере роста проекта. Если не вдаваться в детали архитектуры Grunt, то причина кроется в том, что каждый раз, когда тебе нужно собрать, например, JS-файл, он пересобирает все JS-файлы. Можно постараться ускорить процесс сборки, прописав вручную необходимые связи между файлами, но на проекте со сложным деревом зависимостей файлов это может оказаться чрезмерно сложным.
Несмотря на все это, у Grunt огромная экосистема: сотни плагинов, тысячи проектов, миллиарды разработчиков, вот это все. То есть мало того, что Grunt универсален, еще и плагин под твою задачу уже, скорее всего, написан.
Подводя итог, можно сказать, что Grunt - отличный выбор для маленьких и средних проектов, особенно если раньше ты не настраивал никаких систем сборки. Огромное комьюнити, куча плагинов, понятная документация и даже статьи и доклады на русском языке для тех несчастных, кто без этого не может. Ну и конечно, если в дальнейшем по каким-то причинам Grunt перестанет тебя устраивать, всегда можно перейти на другую систему, лишенную его недостатков.
Gulp
Gulp - активно развивающаяся в данный момент система сборки. В основе ее архитектуры лежит использование потоков в Node.js, что позволяет не записывать на диск временные файлы и папки. Основные достоинства Gulp - скорость и краткость конфига. Причем если первое бесспорно, то краткость по сравнению с Grunt достигается просто за счет другой его структуры. Если в конфиге Grunt ты по отдельности оперируешь плагинами, настраивая каждый из них, то в конфиге Gulp нужно описывать процесс, который должен пройти каждый файл (или набор файлов), чтобы быть собранным. Вот жизненный пример компиляции SASS:
Gulp.task("styles", function() { return gulp.src("styles/*.scss") .pipe(sass({ style: "expanded" })) .pipe(rename({suffix: ".min"})) .pipe(minifycss()) .pipe(gulp.dest("build/styles/css")); });
В первой строчке мы регистрируем задачу для Gulp с именем styles . Затем последовательно описываем, что же нужно сделать с каждым из файлов, подходящим под маску styles/*.scss: компилируем SASS, добавляем.min к имени файла, минимизируем, кладем в конечную директорию. Если с этим файлом понадобится делать что-то еще, мы просто добавим соответствующую команду, например.pipe(добавить комментарий с ASCII-единорогом в начало файла) (надеюсь, для этой повседневной задачи сделают наконец плагин). Мне такой подход к написанию конфига нравится больше: он лучше описывает, что же реально происходит с твоими файлами.
Конечно, пока Gulp проигрывает Grunt по количеству плагинов, но для множества задач плагины есть. Скорее всего, тебе хватит существующих плагинов, а если будет чего-то очень не хватать, всегда можно написать свой (шутка). Кстати, есть пакет gulp-grunt, который позволяет запускать задачи Grunt из Gulp, если прям очень надо.
Если тебе нравится подобный подход к сборке, важна скорость и не нужно выполнять специфические задачи, плагин для которых есть только для Grunt, то Gulp может стать отличным выбором. На настоящий момент Gulp остается самым серьезным конкурентом Grunt.
Broccolli
Самый молодой из рассматриваемых инструментов сборки, находится сейчас, по сути, в стадии разработки. Разработчики Broccolli не скрывают, что вдохновлялись Gulp, однако считают некоторые концепции, лежащие в его основе, ошибочными. Например, они выбрали кеширование всех промежуточных результатов сборки (причем реализуемое каждым из плагинов) для ее ускорения вместо частичной пересборки только требуемых файлов. Также им не понравилось, что Gulp лучше всего оперирует с трансформацией одного файла в один итоговый, то есть один к одному. Чтобы улучшить выполнение операций вида «много к одному», в данный момент Gulp разрабатывает сложную схему с созданием виртуальной файловой системы, что разработчикам Broccolli кажется лишним усложнением и проявлением слабости изначальных концепций Gulp. Broccolli изначально оперирует понятиями деревьев вместо файлов и совершает только трансформации деревьев в другие деревья (пусть даже вырожденные и из одной вершины).
Очень разумный теоретический подход к проблеме сборки не снимает проблемы количества расширений к Broccolli. К сожалению, их около двух десятков и выполняют они только самые базовые задачи. Если хочется попробовать что-то новое, посмотри на Broccolli, он достаточно быстр, активно разрабатывается, но, наверное, для применения на серьезных проектах еще сыроват.
Brunch
Brunch создавался с той же задачей - уделать Grunt по всем фронтам, но подошел к ней совсем с другой стороны. Разработчики Brunch решили взять хорошим пониманием предметной области, то есть сделать менее универсальный инструмент, который будет заточен именно под задачи фронтенда, например без всяких настроек понимать, что *.js - это файл со скриптами, *.coffee - CoffeeScript и так далее. Brunch довольно быстрый, гораздо быстрее Grunt, но чуть медленнее Gulp. К безусловным достоинствам Brunch стоит отнести также действительно компактный конфиг, меньше, чем у Grunt и Gulp, в разы. Вот, например, простой конфиг Brunch:
Exports.config = files: javascripts: joinTo: "javascripts/app.js": /^app/ "javascripts/vendor.js": /^(bower_components|vendor)/ stylesheets: joinTo: "stylesheets/app.css" order: after: ["vendor/styles/helpers.css"] templates: joinTo: "javascripts/app.js"
Заметь, что конфиг можно писать как на CoffeeScript (как в данном случае), так и на обычном JS. Мы создаем обычный модуль, который возвращает JSON с настройками сборки.
Обрати внимание на ключи joinTo и order. Это и есть знание предметной области, о котором я упоминал, - на уровне конфига Brunch знает, что ты, скорее всего, захочешь склеить файлы, причем некоторые раньше остальных. Именно это позволяет заменить 400 строк конфига Grunt на 20–30 строчек Brunch.
Плюс к этому экосистема Brunch гораздо меньше, чем у Grunt и даже чем у Gulp. Плагинов около 50 (сравни с 450+ у Gulp, например), развитие идет не очень быстро, в общем, здесь все довольно печально.
Подводя итог: если тебе очень нравятся короткие конфиги, важна скорость, но при это не нужны никакие особенные действия на этапе сборки, то можно посмотреть на Brunch. Смущает, конечно, небольшое количество плагинов, но, может быть, ситуация поменяется.
ENB
Ну и под конец самое сладкое. Хочу рассказать про систему сборки, разработанную в Яндексе Маратом Дулиным, которая называется ENB. Именно ее мы сейчас и используем на нашем проекте. Ее подход принципиально отличается от всех описанных систем: изначально она создавалась для работы с проектами, использующими BEM-методологию, хотя, как отмечает автор, ее платформа свободна от идеологии BEM и может быть использована для всех проектов подходящей структуры.
Вкратце, в чем суть. В ENB мы оперируем понятием цели, то есть конечного файла, который нужно собрать, или ноды (папки, в общем случае страницы), для которой нужно собрать некоторый набор файлов. Для того чтобы собрать целевой файл, мы используем некоторое количество технологий (грубо говоря, плагинов в терминах Grunt, хотя технологии меньше по размерам и более специализированы). Первым делом ENB определяет исходный набор файлов, которые нужны для сборки целей (этим занимаются несколько базовых технологий, по умолчанию работающие с методологией BEM, то есть они ищут *.bemdecl -файл, в котором прописаны зависимости данной ноды от разных блоков), полностью разворачивает это дерево зависимостей (когда блок, от которого зависит твоя страница, сам зависит от другого, подключаются оба в нужном порядке), а затем находит файлы, необходимые для каждой зарегистрированной технологии. Затем ENB придерживается описанной в конфиге последовательности трансформаций файлов (тут можно проследить некоторую аналогию с Gulp). Несмотря на некоторые отличия от стандартного подхода систем сборки, разобравшись с основными понятиями, дальше работать с ENB довольно легко.
Основные преимущества ENB: скорость сборки, за счет гибкой системы кеширования и возможности обмениваться промежуточными данными между разными технологиями, параллелизации независимых процессов, и выделении самых тяжелых технологий в отдельные субпроцессы. К ENB необычайно просто писать новые технологии, если тебя чем-то не устраивает поведение стандартных.
К недостаткам можно отнести то, что конфиг ENB достаточно многословный, так как есть возможность управлять абсолютно всеми этапами сборки. Плюс ENB все-таки писался для BEM-методологии, и прикрутить его к проекту с совершенно другой структурой потребует лишних телодвижений. Для ENB не так много написанных технологий (порядка 60), но с большинством задач BEM-проектов он справляется на ура.
Подводя итог: ENB - лучший выбор для проектов, основанных на методологии BEM, которую лично я считаю наиболее подходящей для средних и больших сайтов, так как организация кода по блокам рулит и бибикает. Он очень быстрый, собирает десятки страниц и сотни файлов за считаные секунды, несложный в настройке и приятный в использовании. Если твой проект крупный, ты путаешься в коде и правишь файлики по тысяче строк, советую подробнее изучить BEM как способ организации структуры фронтенд-проектов. А когда ты полюбишь BEM, ты полюбишь и ENB, как самый родной инструмент сборки BEM-проектов.
В этой статье мы подробно разберем процесс сборки фронтенд проекта, который прижился в моей повседневной работе и очень облегчил рутину.
Статья не претендует на истину в последней инстанции, так как сегодня существует большое количество различных сборщиков и подходов к сборке, и каждый выбирает по вкусу. Я лишь поделюсь своими мыслями по этой теме и покажу свой workflow.
Мы будем использовать сборщик Gulp . Соответственно у вас в системе должен быть установлен Node js. Установку ноды под конкретную платформу мы рассматривать не будем, т.к. это гуглится за пару минут.
И для начала отвечу на вопрос - почему Gulp?
Из более или менее сносных альтернатив мы имеем Grunt и Brunch .
Когда я только начал приобщаться к сборщикам - на рынке уже были и Grunt и Gulp. Первый появился раньше и по этому имеет более большое коммьюнити и разнообразие плагинов. По данным с npm :
Grunt - 11171 пакет
Gulp - 4371 пакет
Но Grunt мне показался через чур многословным. И после прочтения нескольких статей-сравнений - я предпочел Gulp за его простоту и наглядность.
Brunch - это сравнительно молодой проект, со всеми вытекающими из этого плюсами и минусами. Я с интересом наблюдаю за ним, но в работе пока не использовал.
Приступим:
Создадим папку под наш проект, например «habr». Откроем ее в консоли и выполним команду
Npm init
Можно просто нажать Enter на все вопросы установщика, т.к. сейчас это не принципиально.
В итоге в папке с проектом у нас сгенерируется файл package.json, примерно такого содержания
{ "name": "habr", "version": "1.0.0", "description": "", "main": "index.js", "scripts": { "test": "echo "Error: no test specified" && exit 1" }, "author": "", "license": "ISC" }
Немного видоизменим его под наши нужды:
{ "name": "habr", "version": "1.0.0", "description": "", "author": "", "license": "ISC", "devDependencies": { "gulp": "^3.8.1" } }
в блоке devDependencies мы указали что нам нужен gulp и тут же будем прописывать все наши плагины.
Плагины:
Со стилями я поступаю так же как и с js, но только вместо rigger"a - использую встроенный в SCSS импорт.
Наш main.scss будет выглядеть так:
/* * Third Party */ @import "CSS:../../bower_components/normalize.css/normalize.css"; /* * Custom */ @import "partials/app";
Таким способом получается легко управлять порядком подключения стилей.
Проверим наш таск, запустив
Gulp style:build
Собираем картинки
Таск по картинкам будет выглядеть так:
Gulp.task("image:build", function () { gulp.src(path.src.img) //Выберем наши картинки.pipe(imagemin({ //Сожмем их progressive: true, svgoPlugins: [{removeViewBox: false}], use: , interlaced: true })) .pipe(gulp.dest(path.build.img)) //И бросим в build .pipe(connect.reload()); });
Я использую дефолтные настройки imagemin, за исключением interlaced. Подробнее об API этого плагина можно прочесть .
Теперь, если мы положим какую-нибудь картинку в src/img и запустим команду
Gulp image:build
то увидим в build нашу оптимизированную картинку. Так же gulp любезно напишет в консоли сколько места он сэкономил для пользователей нашего сайта:)
Шрифты
Со шрифтами мне обычно не нужно проводить никаких манипуляций, но что бы не рушить парадигму «Работаем в src/ и собираем в build/» - я просто копирую файлы из src/fonts и вставляю в build/fonts. Вот таск
Gulp.task("fonts:build", function() { gulp.src(path.src.fonts) .pipe(gulp.dest(path.build.fonts)) });
Теперь давайте определим таск с именем «build», который будет запускать все что мы с вами тут накодили
Gulp.task("build", [ "html:build", "js:build", "style:build", "fonts:build", "image:build" ]);
Изменения файлов
Чтобы не лазить все время в консоль давайте попросим gulp каждый раз при изменении какого то файла запускать нужную задачу. Для этого напишет такой таск:
Gulp.task("watch", function(){ watch(, function(event, cb) { gulp.start("html:build"); }); watch(, function(event, cb) { gulp.start("style:build"); }); watch(, function(event, cb) { gulp.start("js:build"); }); watch(, function(event, cb) { gulp.start("image:build"); }); watch(, function(event, cb) { gulp.start("fonts:build"); }); });
С понимаем не должно возникнуть проблем. Мы просто идем по нашим путям определенным в переменной path, и в функции вызывающейся при изменении файла - просим запустить нужный нам таск.
Попробуйте запустить в консоли
Gulp watch
и поменяйте разные файлы.
Ну не круто ли?)
Веб сервер
Что бы насладиться чудом livereload - нам необходимо создать себе локальный веб-сервер. Для этого напишем следующий таск:
Gulp.task("webserver", function() { connect.server({ host: server.host, port: server.port, livereload: true }); });
Тут даже нечего комментировать. Мы просто запустим сервер с livereload на хосте и порте, которые мы определили в объекте server.
Очистка
Если вы добавите какую-нибудь картинку, потом запустите задачу image:build и потом картинку удалите - она останется в папке build. Так что было бы удобно - периодически подчищать ее. Создадим для этого простой таск
Gulp.task("clean", function (cb) { rimraf(path.clean, cb); });
Теперь при запуске команды
Gulp clean
просто будет удаляться папка build.
И напоследок маленькая милость
Этот таск не несет в себе критической функциональности, но он очень мне нравится:)
Gulp.task("openbrowser", function() { opn("http://" + server.host + ":" + server.port + "/build"); });
Когда нам будет нужно, мы запустим его - и у нас в браузере автоматически откроется вкладка с нашим проектом.
Классно же:)
Финальный аккорд
Последним делом - мы определим дефолтный таск, который будет запускать всю нашу сборку.
Gulp.task("default", ["build", "webserver", "watch", "openbrowser"]);
Окончательно ваш gulpfile.js будет выглядеть примерно вот так .
Теперь выполним в консоли
И вуаля:) Заготовка для вашего проекта готова и ждет вас.
Пара слов в заключение
Эта статья задумывалась как способ еще раз освежить в памяти тонкости сборки frontend проектов, и для легкости передачи этого опыта новым разработчикам. Вам не обязательно использовать на своих проектах именно такой вариант сборки. Есть yeoman.io , на котором вы найдете генераторы почти под любые нужды.
Я написал этот сборщик по 2ум причинам.
- Мне нравится использовать rigger в своем html коде
- Почти во всех сборках что я встречал - используется временная папка (обычно.tmp/), для записи промежуточных результатов сборки. Мне не нравится такой подход и я хотел избавится от временных папок.
- И я хотел что бы все это было у меня из коробки:)
Мою рабочую версию сборщика вы можете скачать на моем github .
Надеюсь статья оказалась полезной для вас:)
P.S. обо всех ошибках, недочетах и косяках - пожалуйста пишите в личку
Данный мануал содержит описание полезных и наиболее часто используемых front-end инструментов. Вы сможете узнать процесс установки инструментов и основные моменты работы с ними.
NPM
Введение
В процессе разработки проекта часто приходится добавлять сторонние библиотеки и плагины. В результате разработчику необходимо осуществлять поиск нужной зависимости, скачивать, распаковывать архив и копировать файлы в проект. Пакетные менеджеры помогут автоматизировать данную рутинную работу.
Пакетный менеджер – программное обеспечение, позволяющее управлять процессом установки, удаления, настройки и обновления различных компонентов.
Добавление сторонних библиотек с использованием пакетного менеджера заменяется парой команд в терминале.
Одним из пакетных менеджеров используемых во frontend-проектах является NPM.
npm (Node.js Package Manager) - менеджер пакетов, входящий в состав Node.js. Используется для скачивания пакетов из облачного сервера npm, либо для загрузки пакетов на этот сервер.
Официальный сайт
Начало работы
Для установки npm необходимо скачать и установить NodeJS (npm будет автоматически установлен): https://nodejs.org/en/.
Использование
Установка пакетов
Пакетом называется один или несколько JavaScript-файлов, представляющих собой какую-то библиотеку или инструмент. Для установки пакета с помощью npm необходимо выполнить следующую команду:
Npm install <название пакета>
Для глобальной установки пакета используется ключ -g. После установки пакет вместе с исходниками находится в директории node_modules/.
Проверка версии
Чтобы проверить текущую версию npm, необходимо выполнить команду:
Настройка файла конфигурации
Файл package.json содержит в себе информацию о вашем приложении: название, версия, зависимости и тому подобное. Любая директория, в которой есть этот файл, интерпретируется как Node.js-пакет.
Для создания файла package.json необходимо выполнить команду:
Npm init
После этого необходимо будет заполнить некоторую информацию о проекте.
В данном файле будут храниться наименования и версии всех пакетов необходимых в проекте. С помощью команды npm install можно подгрузить все пакеты, которые находятся в package.json .
Для установки некоторого пакета и автоматическим сохранением в файле package.json используется команда:
Npm install<название пакета> --save-dev
Альтернативы
Yarn
Особенности
- Создание веб-сервера и автоматическая перезагрузка страницы в браузере при сохранении кода, слежение за изменениями в файлах проекта.
- Использование различных JavaScript, CSS и HTML препроцессоров (CoffeeScript, Less, Sass, Stylus, Jade и т.д.).
- Минификация CSS и JS кода, а также, оптимизация и конкатенация отдельных файлов проекта в один.
- Автоматическое создание вендорных префиксов (приставок к названию CSS свойства, которые добавляют производители браузеров для нестандартных свойств) для CSS.
- Управление файлами и папками в рамках проекта – создание, удаление, переименование.
- Запуск и контроль выполнения внешних команд операционной системы.
Работа с изображениями – сжатие, создание спрайтов, изменение размеров (png, jpg, svg и др.). - Деплой (отправка на внешний сервер) проекта по FTP, SFTP и т. д.
Подключение и использование в проекте безгранично большого количества Node.js и Gulp утилит, программ и плагинов. - Создание различных карт проекта и автоматизация другого ручного труда.
Начало работы
В системе должны быть установлены NodeJS и npm.
Шаг 1: Для глобальной установки GulpJS с помощью пакетного менеджера npm необходимо выполнить команду:
Npm install gulp -g
Шаг 2: Необходимо установить его для приложения:
Npm install --save-dev gulp
Подгрузка дополнительных плагинов, которые могут быть использованы при сборке проекта, также осуществляется c помощью npm следующей командой:
Npm install <название плагина> --save-dev
Все установленные плагины находятся в директории node_modules/ .
Использование
Шаг 1: Сперва нужно подключить gulp к проекту. Для этого в файле gulpfile.js прописываем строчку:
Var gulp = require("gulp");
Функция require() позволяет подключать плагины из папки node_modules/.
Шаг 2: С помощью переменной gulp можно создавать таски для сборки проекта:
Gulp.task("exampleTask", function() {});
Метод task
принимает два параметра: название и функцию с телом таски.
Данную инструкцию уже можно выполнить. Для этого в консоли прописываем:
Gulp exampleTask
Основные команды
Ниже представлен более сложный пример инструкции:
Gulp.task("exampleTask", function () { return gulp.src("source-files") .pipe(plugin()) .pipe(gulp.dest("folder")); });
Разберем команды использованные в данном примере:
- gulp.src – выборка исходных файлов проекта для обработки плагином;
- .pipe(plugin()) – вызов Gulp плагина для обработки файла;
- .pipe(gulp.dest(‘folder’)) – вывод результирующего файла в папку назначения.
Маски файлов
Функция gulp.src принимает в качестве параметра маску файлов. Примеры масок:
- ./ – текущая директория;
- ../ – родительская директория;
- js/index.js – файл index.js в папке js;
- js/*.js – все файлы с расширением js в папке js;
- js/**/*.js – все файлы с расширением js в папке js и в ее подкаталогах;
- !js/*.js – исключение файлов с расширением js в папке js.
Потоки
Использование потоков является одним из важнейших преимуществ GulpJS.
Потоки позволяют передать некоторые данные последовательно от одной функции к другой, каждая из которых выполняет некоторые действия с этими данными.
Функция gulp.src() создает поток объектов, представляющих файлы, которые переданы ей в качестве параметра. Далее с помощью функций pipe выстраивается конвейер, по которому передается поток объектов. Данной функции в качестве параметра передается плагин, который каким-либо способом обрабатывает поток объектов.
Ниже представлен пример использования потоков. В данном примере использованы сторонние плагины gulp-jshint и gulp-concat, которые необходимо установить и подключить в gulpfile.js.
Функция gulp.src берет файлы по маске js/*.js . Запускает JSHint и выводит результат. Затем производит конкатенацию файлов и в конце сохраняет полученный файл после конкатенации в директории dist/ .
Gulp.task("example", function () { return gulp.src("js/*.js") .pipe(jshint()) .pipe(concat("index.js")) .pipe(gulp.dest("dist")); });
Сторонние плагины
Рассмотрим пример использования сторонних плагинов. Для этого создадим инструкцию конкатенации файлов js:
Шаг 1: Сперва необходимо подключить плагин командой require:
Var concat = require("gulp-concat");
Шаг 2: Затем нужно создать таск для конкатенации файлов с расширением js находящихся в директории js/ . В конце получившийся файл помещается в директорию dist/js:
Gulp.task("concat", function () { return gulp.src("js/*.js") .pipe(concat("index.js")) .pipe(gulp.dest("dist/js")); });
Gulp concat
Дополнительная информация
Также можно определить таск, который будет вызывать выполнение других тасков.
Gulp.task("build", ["html", "css"]);
Кроме этого существует метод watch для наблюдения изменений в файлах:
Gulp.watch("маска файлов для наблюдения", ["название таски, которая выполнится при изменении файлов"]);
В gulpfile.js можно создать дефолтный таск:
Gulp.task("default", ["task1", "task2"]);
Данный таск запускается из консоли командой:
Основные плагины
- gulp-autoprefixer – автоматически расставляет префиксы к CSS свойствам;
- gulp-browser-sync – создает подключение, после чего производит автообновление страницы при изменении клиентских или даже серверных файлов;
- gulp-uncss – оптимизация CSS файлов. Плагин анализирует HTML код и находит все неиспользуемые и продублированные стили;
- gulp-csso – CSS минификатор;
- gulp-htmlmin – простой HTML минификатор;
- gulp-htmlhint – HTML валидатор;
- gulp-uglify – JavaScript минификатор;
- gulp-concat – конкатенация файлов;
- gulp-webserver – позволяет создать и запустить сервер;
- gulp-jshint – проверка качества JS кода;
- gulp-jasmine – запуск jasmine тестов;
- gulp-jsdoc – генерация JSDoc документации.
С полным списком Gulp-плагинов вы можете ознакомиться по ссылке:
http://gulpjs.com/plugins/
Альтернативы
GruntJS
Особенности
- Поддержка асинхронного тестирования.
- Возможность выставлять наблюдателей (observer) на разные объекты.
Начало работы
Для подключения Jasmine к своему проекту необходимо скачать библиотеку и подключить следующие файлы на главную HTML-страницу:
- lib/jasmine-*/jasmine.js - сам фреймворк;
- lib/jasmine-*/jasmine-html.js - оформление результатов в виде HTML;
- lib/jasmine-*/jasmine.css - внешний вид результата выполнения тестов;
- SpecRunner.html - файл, который следует открыть в браузере для запуска тестов.
Синхронизация с инструментами
GulpJS
Jasmine можно подключить в сборку проекта на GulpJS:
Шаг 1: Вначале необходимо установить плагин gulp-jasmine:
Npm install gulp-jasmine --save-dev
Шаг 2: Затем нужно подключить плагин в файле сборки и создать таску запуска тестов:
Var jasmine = require("gulp-jasmine"); gulp.task("jasmine", function() { gulp.src("файлы тестов") .pipe(jasmine()); });
KarmaJS
(в конце статьи подробнее описана работа с этим инструментом)
Для подключения Jasmine в KarmaJS необходимо:
Шаг 1: Установить KarmaJS:
Npm install -g karma-cli
Шаг 2: Установить плагины необходимые для запуска тестов написанных на Jasmine в браузерах Chrome и PhantomJS:
Npm install karma-jasmine karma-chrome-launcher karma-phantomjs-launcher
Шаг 3: Установить сам Jasmine:
Npm install -g jasmine
Шаг 4: В файле конфигурации karma подключить плагины и прописать путь к тестам.
Использование
Ключевые слова
- describe – определение набора тестов;
- it – определение теста;
- expect – определение ожиданий, которые проверяются в тесте.
Функции describe и it принимают два параметра: первый – название, второй – функция с кодом.
Пример базового теста
describe(“название набора тестов”, function () { it(“название теста”, function () { expect(2+2).toBe(4); }); });Методы проверки результатов
- expect().toBe() – проверка переменных на равенство (‘===’);
- expect().not.toBe() – проверка переменных на равенство (‘!==’);
- expect().toEqual() – проверка на равенство переменных и объектов, включая содержимое;
- expect().toBeDefined() – проверка на существование;
- expect().toBeUndefined() – проверка на несуществование;
- expect().toBeNull() – проверка значения переменной на null;
- expect().toBeTruthy() – проверка на истинность;
- expect().toBeFalsy() – проверка на ложность;
- expect().toBeLessThan() – проверка на то, что значение должно быть меньше чем;
- expect().toBeGreaterThan() – проверка на то, что значение должно быть больше чем;
- expect().toBeCloseTo() – проверка на то, что значение должно быть близко к числу;
- expect().toMatch() – проверка на соответствие регулярному выражению;
- expect().toContain() – проверка на содержание в массиве;
- expect().toThrow() – проверка вызова исключения;
- expect().toHaveBeenCalled() – проверка вызова функции.
Дополнительные функции
Во избежание копирования какой-либо логики, используемой в тестах, используются функции beforeEach/afterEach . Они запускаются соответственно перед/после каждого теста.
Для тестирования асинхронных вызовов используются функции runs и waitsFor .
- runs – принимает асинхронную функцию для выполнения;
- waitsFor – принимает три параметра: первый – функция, которая должна вернуть true, если асинхронный вызов в функции runs был выполнен, второй – сообщение об ошибке, третий – ожидание в миллисекундах.
Наблюдатели
Возможность отслеживания вызова функций производится с помощью spyOn . Данная функция принимает два параметра: первый – объект, для которого осуществляется вызов функции, второй – имя функции, которую необходимо отслеживать.
If(“проверка вызова функции”, function () { spyOn(exampleObject, "exampleFunction"); exampleObject.exampleFunction(); expect(exampleObject.exampleFunction).toHaveBeenCalled(); });
При тестировании с использованием spyOn можно отслеживать количество вызовов, их параметры и каждый вызов в отдельности.
Для создания функции без реализации можно воспользоваться createSpy . Функция createSpy принимает имя функции для идентификации.
If(“проверка вызова функции”, function () { var example = createSpy("EXAMPLE"); example(“param1”, “param2”); expect(example.identify).toHaveBeenCalledWith(“param1”, “param2”); expect(example.calls.length).toEqual(1); });
Создание объекта заглушки осуществляется с помощью createSpyObj . В качестве параметров createSpyObj принимает имя объекта и массив строк, являющийся списком методов объекта заглушки.
Альтернативы
Mocha
Использование
Генерация документации производится из комментариев исходного кода.
Загрузка...
