Уже давно инструменты сборки фронтенда перешли из разряда экзотики в необходимую часть работы над проектом. Я хочу поделиться некоторыми наработками по части организации проекта, его структуры, рассказать, какие задачи я решаю с помощью сборки и какими инструментами.
Мы напишем небольшое тестовое приложение в связке Backbone + Require.js. Настроим окружение для работы над проектом в режиме “девелопмента” и “продакшена”, посмотрим на их отличия. И в конце напишем задачи для сборки проекта с помощью инструмента сборки gulp и его плагинов.
Будут рассмотрены такие вопросы: работа со стилями sass с использованием sourcemaps, склеивание и сжатие js-файлов, сборка requirejs с помощью rjs, препроцессинг html, очистка и копирование файлов, оптимизация изображений, поднятие локального веб-сервера и режим наблюдения – watch-таски.
Добро пожаловать в статью, будет много интересного!
P.S. Материала много, поэтому статья будет разбита на 3 части: основы сборки и организация проекта, написание тестового приложения на Backbone + Require.js и собственно сборка с помощью gulp.
Зачем нужна сборка фронтенда.
Один из самых важных принципов в разработке – это модульность. Разбиение кода проекта на множество небольших, в идеале слабосвязанных между собой кусочков-модулей. Это касается далеко не только javascript-кода. Это относится и к стилям, и html-шаблонам, к различным библиотекам.
Примерно так может выглядеть структура простого приложения, написанного на Backbone + Require.
И это небольшой тестовый проект, в реальном приложении файлов может быть сотни и тысячи. Заставлять браузер пользователя делать сотни http-запросов по меньшей мере негуманно. Мы должны обеспечить максимально быструю загрузку написанного нами сервиса. Поэтому одна из самых важных задач инструментов сборки – это минификация, уменьшение количества используемых на проекте файлов, склеивание их в бандлы. На выходе мы должны иметь более краткую структуру, например, вот такую:
Разница хорошо заметна: вместо десятков файлов мы имеем один index.html, один css-файл, оптимизированные и сжатые изображения в отдельной папке, хотя на скриншоте этого и не видно 🙂
А также самое интересное: в папке js мы получили всего 3 сжатых файла.
P.S. Почему три, а не один, расскажу позже.
Замечу, что это реальная структура тестового приложения, которое мы вскоре напишем.
Я описал лишь одну причину использования инструментов сборки, но она уже достаточна, чтобы начать использовать gulp, grunt, webpack или что-то подобное в своих проектах. Причем не имеет значения, пишем ли мы громадный сервис, небольшое SPA (как в нашей статье) или landing page. Принципы сборки одинаковы для всех проектов и различаются лишь разнообразием задач и подходов к их решению. В нашем примере мы создадим такую структуру, которая может сколь угодно расшириться в дальнейшем, но на выходе всегда будет аккуратная стопка файлов, готовая к выливке на ваш продакшен – боевой сайт.
Как правильно организовать проект.
Принцип такой: есть раздел с девелоперскими файлами, есть с собранными и все остальное, что это добро обслуживает. Создадим в корне проекта 2 папки: src и build. В src и только в src мы будем работать, создавать новые файлы, редактировать их и вообще развлекаться. На скриншоте выше, там, где пара десятков файлов, Вы видели именно содержимое папки src нашего тестового проекта. А чуть ниже несколько аккуратных файлов из папки build. Она формируется только автоматически, инструментами сборки, ничего самим там править не нужно. Все равно при каждой сборке ее содержимое затирается новыми файлами (а в режиме development папки build вообще нет – удаляется, дабы не мозолить глаза)
Кроме src и build в корне будут лежать файлы package.json, gulpfile.js, папка node_modules и опционально, .gitignore (если Вы работает с гитом). У меня еще можно заметить папку logs – это порождение apache и давняя привычка держать логи проекта в его же папке, конечно, исключив ее из репозитория гита 🙂
Вот так выглядит структура проекта целиком:
По содержимому build, думаю, вопросов нет, по src поясню подробнее:
- 1. html – index.html, корневой индексный файл проекта. Почему не сразу в корне src? Потому что он будет препроцесситься и создаваться gulp-ом. Каким образом, узнаем немного позже, когда вплотную займемся сборкой.
- 2. img – изображения, не сжатые, обычные
- 3. js – вся javascript-движуха проекта, модели и представления Backbone
- 4. lib – сторонние библиотеки, вроде backbone.js, require.js, lodash.js и прочих
- 5. scripts – js-скрипты, которые необходимы на боевом сайте, но не нужны в режиме разработки. Имеются в виду коды для аналитики, различных экспериментов и прочих маркетинговых штук.
- 6. styles – sass-файлы со стилями. В эту же папку будет складываться собранный css-файл (только для режима девелопмента)
- 7. tpl – html-шаблоны. Используются представлениями Backbone с помощью плагина require.js text
Внешний вид тестового приложения довольно неказистый. Вы можете сказать, что подобная хрень делается парой строк html и css-кода без единого js-файла.
Но мы преследуем цель не нарисовать красивую картинку, а создать надежную структуру проекта и рассмотреть как можно больше аспектов сборки. Когда проект разрастется до сотни файлов, мы уже будем готовы к этой напасти и легко управимся с возросшими объемами. Поэтому несмотря на малость и внешнюю убогость тестового приложения, мы узнаем принципы сборки для больших и сложных проектов.
Какие задачи сборки мы решим.
Напомню, что мы договорились о двух режимах сборки: development и production. Все наши задачи мы будем писать, помня об этих двух режимах. Не все операции нам нужны в процессе разработки, и не все в сборке для продакшена.
Вот список того, чем мы займемся после написания тестового приложения:
- 1. Очистка файлов и папок от результатов предыдущей сборки
- 2. Сборка css из sass-файлов, со сжатием и без
- 3. Подключение sourcemaps к стилям, заодно покажу на примере, зачем это нужно
- 4. Сборка js-бандла с помощью requirejs
- 5. Склеивание и сжатие отдельных js-файлов (аналитики)
- 6. Препроцессинг html
- 7. Оптимизация и сжатие изображений
- 8. Поднятие локального веб-сервера
- 9. Задачи наблюдения за файлами при работе в режиме девелопмента – watch-таски
- 10. Сбор отдельных задач в кучу – итоговые таски для production-сборки и development-работы
Итак, мы порассуждали, зачем вообще нужна сборка фронтенда, определились со структурой проекта, подробно разобрали, что мы хотим от сборки и в общих чертах поговорили про тестовое приложение. В следующей части статьи мы займемся написанием простенького Backbone-приложения в связке с Require.js. Если Вы не знакомы с Backbone и/или Require.js, то ничего страшного нет. Собственно Backbone-овского кода в приложении мало. Вы легко можете вместо него использовать любимую библиотеку или просто писать код на javascript/jquery и пропустить раздел настройки requirejs.