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

Я тоже хочу поделиться своим опытом работы с Webpack, предложив вашему вниманию версию конфигурационного файла, с широким функционалом. В него уже интегрированы две самые популярные по сей день библиотеки – точнее, одна библиотека (jQuery) и один фреймворк (Bootstrap). При желании их можно отключить.

Сам код вы можете скачать здесь.

А зачем нам вообще Webpack?

Как гласит нам мудрая википедия, Webpack – это пакет модулей JavaScript с открытым исходным кодом. Он сделан в основном для JavaScript, но он может преобразовывать внешние ресурсы, такие как HTML, CSS и изображения, если включены соответствующие загрузчики.

Сам по себе Webpack ничего не умеет. Он организует работу плагинов, необходимых для среды разработки, и формирует файлы вашего проекта. Типичные задачи, которые решают при помощи планировщика:

  1. Работа с модулями JavaScript – это, собственно, основная задача Webpack. Планировщик (а точнее, запущенный им плагин) обходит весь ваш JS-код, анализирует импортируемые и экспортируемые модули и объединяет их в один исполняемый файл. Файл автоматически подключается в index.html перед закрывающим тегом body.
  2. Работа с препроцессорами CSS – ваш код в формате SCSS или SASS компилируется в CSS и собирается в один файл (бандл), который также подключается в head сайта.
  3. Минификация – сжатие кода JavaScript и CSS, удаление пробелов и комментариев.
  4. Транспайлинг – вы пишете на современном JS-синтаксисе, со стрелочными функциями и прочими удобствами, а код автоматически преобразуется в формат, понятный старым браузерам.
  5. Подключение библиотек и плагинов JS – вместо того, чтобы руками скачивать файлы и подключать их в код, вы можете добавить их в настройки пакета, они будут скачаны и установлены, при этом соблюдаются все взаимные зависимости (во всяком случае, в теории).
  6. Запуск локального сервера для разработки. Вы просто работаете с кодом, который при сохранении изменений автоматически перекомпилируется и страница выводится на экран.
  7. Проверка синтаксиса. Существует множество плагинов, которые с удовольствием проверят ваш синтаксис JS, CSS, HTML и прочих ресурсов, и выдадут в консоль список ошибок.
  8. Два режима работы. Логика работы Webpack предполагает два режима работы – разработка и продакшен.

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

На продакшене все файлы собираются в папку dist. При этом локальный сервер нам не нужен, source map тоже не нужны, зато необходима минификация файлов. Это режим генерирует код дольше. То, что получается в итоге – это и есть готовый проект, который можно (и нужно!) будет разместить на сервера.

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

За подробностями – добро пожаловать в официальную документацию.

Как это выглядит?

В типичный джентльменский набор для сборки Webpack входят следующие файлы:

webpack.config.js – в нём содержится модуль с конфигурацией Webpac, который описывает что и в какой последовательности должен делать наш планировщик.

package.json – файл подключения пакетов. В нём содержатся директивы для NPN, какие плагины нужно запустить для работы, что из этого будет необходимо для самого сайта, а что – только для процесса разработки. Здесь же описываются данные о репозитории, разработчике и проекте.

package-lock.json – файл с взаимными зависимостями модулями. Генерируется автоматически, править его руками крайне нежелательно.

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

.gitignore – список файлов и каталогов, которые не будут добавляться в ваш гит-репозиторий. В него в обязательном порядке нужно добавить папку node_modules, а также желательно добавить каталог dist.

.eslintrc – файл с настройками линтера. Линтер – плагин, проверяющий ваш JavaScript код.

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

Каталоги

src – папка с исходниками. Здесь размещается основной файл проекта index.html, папка scss со стилями, папка img c картинками, папка js c кодом JavaScript.

dist – папка, в которую будет компилироваться ваш проект для размещения на сервере. Создавать её руками не нужно, если её нет, её создаст сам Webpack

Как с этим работать?

Если вы раньше не работали с Webpack, Gulp, Grunt или тому подобными программами, то вам нужно сделать несколько предварительных шагов.

1 Установите Node.js и пакетный менеджер NPM. Просто скачиваете его с официального сайта и устанавливаете.

2 Проверьте корректность работы, открыв консоль и введя команду node -v, которая покажет версию Node․js‚ установленную в вашей системе. Версия NPM проверяется командой npm -v.

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

4 Откройте консоль, перейдите в папку проекта. Запустите установщик пакетов командой

npm install

Менеджер создаст папку node_modules, скачает туда из хранилища все файлы и пропишет зависимости. Если вы ещё не знакомы с этой системой – не удивляйтесь размерам папки и количеству лежащих в ней файлов.

5 Для входа в режим разработчика наберите в консоли:

npm run start

Должен запуститься локальный сервер, собраться ваш проект и отобразиться на экране. Для выхода из режима просто два раза нажмите в консоли Ctrl+C и подтвердите выход введя Y.

Стили вы можете править в файла scss, которые лежат в папке src\scss, код js писать в папке src\js, html – в src\index.html.

6 Для сборки сайта на продакшн запустите команду:

npm run build

Папка dist будет очищена от старых файлов (или создана заново, если её нет), проект собран в ней.

7 Настройка. Как уже говорилось, в проект интегрированы библиотека jQuery и фреймворк Bootstrap. Так что если вам нужно, можно просто писать в js-файле код с обычный вызов функционала через $ или jQuery. Если вы не планируете использовать эту библиотеку, можете закомментировать строки 69-72 в файле webpack.config.js. В файле package.json в разделе dependencies можно удалить строку jquery.

Стили Bootstrap импортируованы через файл index.scss, скрипты через js/index.js. Если вы не планируете его использовать, удалите строки импорта, а также удалите установку фреймворка в файле package.json в разделе dependencies — строки bootstrap и popper.js.

ESLint по умолчанию отключен. Лично мне мешает, когда программа не хочет запускаться из-за того, что, например, в конце файла две пустых строки вместо одной. Или потому что какая-то из строк получилась слишком длинной. Но если вы планируете работать с проверкой синтаксиса, то раскомментируйте строку в файле webpack.config.js в функции jsloaders. Для настройки правил работы линтера редактируйте файлы .eslinrc и .eslintignore.

Для понимания того, что и как делает сборка, достаточно немного помедитировать над файлами webpack.config.js и package.json. Пожалуй, единственное, на что стоит обратить внимание, это две переменные isDev и isProd. В режиме разработке первая из них true, вторая false, в режиме продакшена – наоборот. В зависимости от них подключаются различные настройки плагинов. Сами настройки для каждого конкретного плагина можно посмотреть в документации, расширяя и модифицируя функционал сборки до нужного именно вам.

Неизбежные минусы

Про возможности Webpack я уже рассказал, так что стоит немного коснуться и минусов такого подхода.

Во-первых, это отсутствие обратной совместимости. Например, в случае с Gulp многие пользователи столкнулись с тем, что 3-я версия внезапно перестала работать с новыми версиями Node.js. А 4-я версия настраивалась совсем иначе и требовала новых конфигурационных файлов. Практически вся инфраструктура планировщиков разрабатывается опенсорсно и никто не гарантирует вам, что завтра не выйдет обновление, которое всё поломает. Если вы один раз внедрили Webpack в свой проект, готовьтесь к тому, что придётся вникать в то, как работает его конфигурационный файл и постоянно его переписывать по новым канонам. Которые всё время меняются.

Во-вторых, это достаточно долго и громоздко. Если у вас есть время, чтобы разворачивать окружение, настраивать конфиги, обновлять плагины – хорошо. Но иногда нужно написать простую страничку и для неё всё это сложное окружение может оказаться просто избыточным. Многим просто не нравится постоянно таскать и обновлять папку node_modules. Написать в отдельный файлик стили и js-код руками может быть гораздо проще и надёжнее.

В-третьих, проблемы с масштабируемостью. Логика Webpack изначально конструировалась под JS-разработку и SPA. Если у вас несколько html-файлов и в каждый надо подключать разные стили и разные модули, то над этим уже можно поломать голову. А если ваш фронтенд ещё нужно каким-то сложным образом интегрировать в не менее сложный бекенд, проблемы могут возрасти на порядок.

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